From nobody Mon Jun 1 02:56:52 2020 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 40B6D3A0ECF for ; Mon, 1 Jun 2020 02:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYk2hjf1e5cc for ; Mon, 1 Jun 2020 02:56:50 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 281C73A0ECE for ; Mon, 1 Jun 2020 02:56:50 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id p21so3284051pgm.13 for ; Mon, 01 Jun 2020 02:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Lt+E5ipNf/WV+2Y6QNyn5sofWm3eHCl0wHdeWBwbFGU=; b=V01Yepk7FLCbKamlbX9W5SXja3Dvn0YLahLiei7Nu5qR5EKoMNQacS961XJBUOiKCh d95+UxG8CkCWNL5mId0YBWY+sG3hE5ILk114vdekt2yzHAFpJ7CX8PaRmmshLEK09Koi /5fW0IjMr3lj+hOwKEZW2TsJfrKAqPDW8lzNb43XE4/eGyfFIaFCFwfAo3KNb3w08PiU QcsSBt6NhB4kseCDeYAOKgMnoGkhi6SxCREs2RiNsLjfn+tKUSRxBhuM8ObGd5MXf32n +rXU35RXegbyR7SN1Khlg03QASC7GfUmBKGZXl+H89HMKZqA+vV9uTdZGdHAgj4b2FUW 9BqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Lt+E5ipNf/WV+2Y6QNyn5sofWm3eHCl0wHdeWBwbFGU=; b=tioE88DdeWBlKGKYClgxNPUyYGQiP27p+rpQxPnD8FGS1UVvkY1lRKc98l4BHpyrHQ 676faYSx0IukpSgFWWkZYWT+3Yfny0C+0YHFiTNYXvFkKQEPx0I+yeNKv2VKoD1POXdq bN7j0f57Tl8KhqdDMNvnu1Ri/msYEFAIBu5PT0WsU+3VbOH6B9IRKrvm7y3WKHxYY3x9 47mSsjx7B+hANjQG8dAhGCZ4+K6iZbWPs/0qunGxsBgDMq1LWv3oiSEKt8vGQ5wIftTq VZwtCfaU++5GuoOgi3BZs2cePTega2ZMLdwapTa4dMbBkHaHLstDyNuortcAl+RpL1oo K5aA== X-Gm-Message-State: AOAM533BAkLiIjFTMHUzUOgws1QizHK2Hnv2ce+8yL4tB/hY7T9WpFB1 lzFpXIvMYW7A3Nlten3B+O+RBR9m X-Google-Smtp-Source: ABdhPJy6HNY2mpJ47CoSfabcKy5fEmkypnHbXjf1fDfPHeNwlHb64KxIo8H3iDax/F9JlNvqWjZafA== X-Received: by 2002:a62:1ac7:: with SMTP id a190mr17847578pfa.194.1591005409230; Mon, 01 Jun 2020 02:56:49 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id gv4sm6886908pjb.6.2020.06.01.02.56.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 02:56:48 -0700 (PDT) From: OKUMURA Shinji To: "Dale R. Worley" Cc: sipcore@ietf.org References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> Message-ID: Date: Mon, 1 Jun 2020 18:56:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 09:56:51 -0000 Hi, I've not intended to suggest a common solution to the fork-issue. I am interested in how the fork does not happen. It is related to the behavior of proxies and a UAS in the 1st phase that you mention. My suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as possible. Considering backward compatibility, rules are as follows. a) A UAC and proxies should not insert a Session-Expires header. b) A UAC and proxies may insert a Min-SE header or increase the value of it. c) A UAS may insert a Session-Expires header into a 200 response. d) A proxy may insert a Session-Expires header into a 200 response, but must not modify it. Of course legacy proxies will return 422, but this is unavoidable. In that case, the following rule may be useful. e) If a proxy increases the value of a Min-SE header and it becomes greater than the value of a Session-Expires header, then a proxy should increase the value of a Session-Expires header to the value of a Min-SE header. However, this rule can be problematic in terms of backward compatibility. Shinji On 2020/05/29 11:30, Dale R. Worley wrote: > OKUMURA Shinji writes: >> As you point out, the other responses(407, 420, ...) cause the same problem. >> But session-timer is essentially a kind of pre-condition, so I'd like >> to avoid incoming calls to fail because of it. And I'd like to sort >> out also the rules in early dialog. > >> On 2020/05/27 19:16, Christer Holmberg wrote: >>> A proxy rejecting a request is not unique to the session-timer. >>> >>> If Alice receives a 422 she can send a CANCEL (if other early dialogs >>> have been established), and then a new initial INVITE. > > (This has a larger scope than just session-timers.) > > I don't know if the above writers intended this point, but reading what > they have said suggests to me this possible behavior for proxies (which > I don't recall seeing suggested): > > Note that 422 is one of a number of "pre-condition failure" response > codes. Those have the properties (1) when they are generated, they are > generated nearly immediately from the INVITE, and (2) the UAC can adjust > the INVITE to prevent them. > > Suppose that if a proxy receives one of these "pre-condition failure" > responses, it immediately (or with short delay on a human scale) cancels > all remaining forks of the transaction and returns the failure response > upstream. > > The effect is to split the "early dialog" phase into two sub-phases, (1) > a very short phase where the forking of the INVITE effectively probes > for proxies and UASs that object to the the INVITE for "pre-condition" > reasons, and (2) a longer phase which resembles the current early dialog > phase. > > There are probably refinements needed to make this work in all cases. > > Dale > From nobody Mon Jun 1 10:02:58 2020 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 803583A1248 for ; Mon, 1 Jun 2020 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bc70YdVYzWJX for ; Mon, 1 Jun 2020 10:02:54 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 1EA9F3A127F for ; Mon, 1 Jun 2020 10:02:53 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id b18so8574534oti.1 for ; Mon, 01 Jun 2020 10:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TpATjDWFYLXVHhfG07PlmQFoBqSE3jE4zJhyw69B+tQ=; b=nSO9SlUv5Keh7pFx3Dphw855WSSFLDpTNubt8YddNFu2MZEGCAmMQ6VK2Rlyyhgd4X qrlEGOU2tR4Z0tUSNOn5XcEDHk1JBIgKIb0MKF6G64z8cIKm2j0B3+/tLDnxo5XZPsP7 tW/lKkeJsdGo8PT7eRyfoF0HVMKxaNBoB7rUEpMeOIHSN61fvx8E36voyCzg/xXaWsXu aq/O7L9Wm4fuY8QG2OehXLUan32DlCloTLX4++KwTunu7R88aIkxC8gcpfqxJ1qpF5lR FTujQPZsU8K52/MQZ9IVaA4dLW+S9PY2p/pkTzbSaTxIlrEbyZUcUVgfiVzXSAUZnG+h G+4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TpATjDWFYLXVHhfG07PlmQFoBqSE3jE4zJhyw69B+tQ=; b=Q+fKPPhtVLoZWUSH/ExbsIe82SUg05d2o0UndBmG5OQBDMQQABsfpsgtfTGcHHKRsx aAWHEohu7RLpBj8+FuA9UPN8do+fkLrXHP6tM2e1lpArGR42FyzndWUh+aa7lK1c+Cgq qV6DLww34Tt86YlGgQxu5VZvfnkbVVZVN/F0ZRExly7lADNdkLhxQXIUAklaZWsp4LlV 2u0PLDQ2g0+K/XbyidUarbBle+8jYD65s91Nq1hUpUXxzYNplins+B9MBNKhsH20Z5Z3 MGGOd2tod32wlielzlBlgo1JcwjmYfoD8ZnMaoBP672SxJ553Ek59uYnW/+I4a0KZgkL TYNA== X-Gm-Message-State: AOAM530pUZ/fq3oOgQLYkB1ZRcvFRxcbdLbNyqLZE7xjsRYibZ100Mbz jcOuH1yJwxmZArse10awpCtJei3uiRs= X-Google-Smtp-Source: ABdhPJx+BVEfSvpvGNoj50/ItV4cbz2L/83iMbB1MxCncdFE+ZH67aJ5F5eNvs38oQKT9mNkYUJQ+Q== X-Received: by 2002:a05:6830:12c1:: with SMTP id a1mr12495966otq.123.1591030972759; Mon, 01 Jun 2020 10:02:52 -0700 (PDT) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com. [209.85.167.177]) by smtp.gmail.com with ESMTPSA id w197sm3958659oif.1.2020.06.01.10.02.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 10:02:51 -0700 (PDT) Received: by mail-oi1-f177.google.com with SMTP id c194so4689865oig.5 for ; Mon, 01 Jun 2020 10:02:51 -0700 (PDT) X-Received: by 2002:aca:72c2:: with SMTP id p185mr207540oic.139.1591030971345; Mon, 01 Jun 2020 10:02:51 -0700 (PDT) MIME-Version: 1.0 References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Mon, 1 Jun 2020 13:02:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "Dale R. Worley" , SIPCORE Content-Type: multipart/alternative; boundary="000000000000dfb21505a708c365" Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 17:02:57 -0000 --000000000000dfb21505a708c365 Content-Type: text/plain; charset="UTF-8" Shinji, The main purposes of session timers is to allow SIP proxies to maintain dialog state for billing and other purposes. Proxies are the main agents that insert Session-Expires header. In most cases there is no reason for UA to use session timers since they can normally monitor call presence without it. Your proposal makes the most common use case for session timers impossible. Min-SE exists mainly for the purpose of preventing badly behaving proxies or UA from overload proxies on the call path or UAS. Not allowing proxy to send 422 creates a big security risk. My general attitude is that parallel forking is broken for a lot of use cases anyway, so it should be avoided. I do not think a lot of production deployments are actually use parallel forking. Most of the UA would not handle multiple 200 OK responses that can be created as a result of parallel fork. Session timers are, on the other hand, are used a lot. So I would prefer to live with broken or under-specified parallel forking vs breaking session timers. Thank You, _____________ Roman Shpount On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji wrote: > Hi, > > I've not intended to suggest a common solution to the fork-issue. I am > interested in how the fork does not happen. It is related to the behavior > of proxies and a UAS in the 1st phase that you mention. My suggestion is > that a UAS and proxies SHOULD avoid returning 422 as much as possible. > > Considering backward compatibility, rules are as follows. > > a) A UAC and proxies should not insert a Session-Expires header. > b) A UAC and proxies may insert a Min-SE header or increase the value of > it. > c) A UAS may insert a Session-Expires header into a 200 response. > d) A proxy may insert a Session-Expires header into a 200 response, but > must not modify it. > > Of course legacy proxies will return 422, but this is unavoidable. > In that case, the following rule may be useful. > > e) If a proxy increases the value of a Min-SE header and it becomes > greater than the value of a Session-Expires header, then a proxy should > increase the value of a Session-Expires header to the value of a Min-SE > header. > > However, this rule can be problematic in terms of backward compatibility. > > Shinji > > On 2020/05/29 11:30, Dale R. Worley wrote: > > OKUMURA Shinji writes: > >> As you point out, the other responses(407, 420, ...) cause the same > problem. > >> But session-timer is essentially a kind of pre-condition, so I'd like > >> to avoid incoming calls to fail because of it. And I'd like to sort > >> out also the rules in early dialog. > > > >> On 2020/05/27 19:16, Christer Holmberg wrote: > >>> A proxy rejecting a request is not unique to the session-timer. > >>> > >>> If Alice receives a 422 she can send a CANCEL (if other early dialogs > >>> have been established), and then a new initial INVITE. > > > > (This has a larger scope than just session-timers.) > > > > I don't know if the above writers intended this point, but reading what > > they have said suggests to me this possible behavior for proxies (which > > I don't recall seeing suggested): > > > > Note that 422 is one of a number of "pre-condition failure" response > > codes. Those have the properties (1) when they are generated, they are > > generated nearly immediately from the INVITE, and (2) the UAC can adjust > > the INVITE to prevent them. > > > > Suppose that if a proxy receives one of these "pre-condition failure" > > responses, it immediately (or with short delay on a human scale) cancels > > all remaining forks of the transaction and returns the failure response > > upstream. > > > > The effect is to split the "early dialog" phase into two sub-phases, (1) > > a very short phase where the forking of the INVITE effectively probes > > for proxies and UASs that object to the the INVITE for "pre-condition" > > reasons, and (2) a longer phase which resembles the current early dialog > > phase. > > > > There are probably refinements needed to make this work in all cases. > > > > Dale > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000dfb21505a708c365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 Shinji,

=
The main purposes of session timers is to allow SIP = proxies to maintain dialog state for billing and other purposes. Proxies ar= e the main agents that insert Session-Expires header. In most cases there i= s no reason for UA to use session timers since they can normally monitor ca= ll presence without it. Your proposal makes the=C2=A0most common use case f= or session timers impossible.

Min-SE exists mainly for the purpose of=C2=A0preventing badly behaving = proxies or UA from overload proxies on the call path or UAS. Not allowing p= roxy to send 422 creates a big security risk.

My general attitude is that parallel forking is broken = for a lot of use cases anyway, so it should be avoided. I do not think a lo= t of production deployments are actually use=C2=A0parallel forking. Most of= the UA would not handle multiple 200 OK responses that can be created as a= result of parallel fork. Session timers are, on the=C2=A0other hand, are u= sed a lot. So I would prefer to live with broken or under-specified paralle= l forking vs breaking session timers.

Thank You,
_____________
Roman Shpo= unt


On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
=
Hi,

I've not intended to suggest a common solution to the fork-issue. I am = interested in how the fork does not happen. It is related to the behavior o= f proxies and a UAS in the 1st phase that you mention. My suggestion is tha= t a UAS and proxies SHOULD avoid returning 422 as much as possible.

Considering backward compatibility, rules are as follows.

a) A UAC and proxies should not insert a Session-Expires header.
b) A UAC and proxies may insert a Min-SE header or increase the value of it= .
c) A UAS may insert a Session-Expires header into a 200 response.
d) A proxy may insert a Session-Expires header into a 200 response, but mus= t not modify it.

Of course legacy proxies will return 422, but this is unavoidable.
In that case, the following rule may be useful.

e) If a proxy increases the value of a Min-SE header and it becomes greater= than the value of a Session-Expires header, then a proxy should increase t= he value of a Session-Expires header to the value of a Min-SE header.

However, this rule can be problematic in terms of backward compatibility.
Shinji

On 2020/05/29 11:30, Dale R. Worley wrote:
> OKUMURA Shinji <ietf.shinji@gmail.com> writes:
>> As you point out, the other responses(407, 420, ...) cause the sam= e problem.
>> But session-timer is essentially a kind of pre-condition, so I'= ;d like
>> to avoid incoming calls to fail because of it. And I'd like to= sort
>> out also the rules in early dialog.
>
>> On 2020/05/27 19:16, Christer Holmberg wrote:
>>> A proxy rejecting a request is not unique to the session-timer= .
>>>
>>> If Alice receives a 422 she can send a CANCEL (if other early = dialogs
>>> have been established), and then a new initial INVITE.
>
> (This has a larger scope than just session-timers.)
>
> I don't know if the above writers intended this point, but reading= what
> they have said suggests to me this possible behavior for proxies (whic= h
> I don't recall seeing suggested):
>
> Note that 422 is one of a number of "pre-condition failure" = response
> codes.=C2=A0 Those have the properties (1) when they are generated, th= ey are
> generated nearly immediately from the INVITE, and (2) the UAC can adju= st
> the INVITE to prevent them.
>
> Suppose that if a proxy receives one of these "pre-condition fail= ure"
> responses, it immediately (or with short delay on a human scale) cance= ls
> all remaining forks of the transaction and returns the failure respons= e
> upstream.
>
> The effect is to split the "early dialog" phase into two sub= -phases, (1)
> a very short phase where the forking of the INVITE effectively probes<= br> > for proxies and UASs that object to the the INVITE for "pre-condi= tion"
> reasons, and (2) a longer phase which resembles the current early dial= og
> phase.
>
> There are probably refinements needed to make this work in all cases.<= br> >
> Dale
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000dfb21505a708c365-- From nobody Mon Jun 1 18:51:12 2020 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 7242B3A0807 for ; Mon, 1 Jun 2020 18:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quKcJA2wE-61 for ; Mon, 1 Jun 2020 18:51:08 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 E2AD43A0801 for ; Mon, 1 Jun 2020 18:51:08 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id r10so4333450pgv.8 for ; Mon, 01 Jun 2020 18:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7vSKmdYLk4je9/gR1AU5Twx3n179QaSArSs0m7j7TDA=; b=T7byUV8TmSJst9nWtb0Qzzh/3r5xi2ol1IN63VBlEWUMmG4BXNpi29x6rHCmBhSNpq nzymNsphZ8HjX85Heq4pByDI7wfGojmqmSQPZqIQ3AM95gLrt1AnJrEUxyx36ylIxU+l /5F3sLdpf/2lIxEiOieU1Znf+YY8xpYZuj3a/xJVV6TVJS020AtyRkMNfIV7+HOxUtTm lD77MiV/d+9kjSxKnkJRXKNKSgVYw/Tb+xp7WFXV5V6UFmTQl883rmEYRPgosQRMeD97 faUrJXecdytcVQqmsHlynLHrZ8qGjfpr0xfOlUltVtJHrFUnilpb7vZg/+SKQlGEwav9 85MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7vSKmdYLk4je9/gR1AU5Twx3n179QaSArSs0m7j7TDA=; b=sV66OoUCnagcKXCH0jtq514bGURVUAF0fD1kjPtkpbe8ncYqNLOJBrmglq1BfnaErD Kj9ZP3xoe+1aQpFLlixfK450AQ1sCHx5BxDHZG6JpTTXpWhvVbcMyJtZdmQzhSxN8dYu UayZcGTDVymCSVxrX+AodudW2TftdVt9roG+Rd008e1JNwKf+8095ijSpAlTMUlc0aZ3 oGfxN3rZppifX3X63a7pANdV+vxaPniHqeSYoY6bjvuBY9vd6E/5gVruJuEp1aYXGfaj paDp+l7cbRc1Kt51448jOcmKmIWBu7XfQMnIIj//BglQ3M6mu1G/2T8XmmIX/KjevCIH iNpg== X-Gm-Message-State: AOAM530db8f+6aCGSf+diNh71p/2CcMD1Pnk+dnspqssb8yrnZJiQaf0 O3Bdi+379H6sIGGFYzQl3VsM9KOk X-Google-Smtp-Source: ABdhPJy5avEtvwVZ+l4JW2lhlxzDWjKBIkAMhPbqk+UrIXPUehYbL2rAD4TZPrurVgjDHtP30J3uag== X-Received: by 2002:a63:fa4d:: with SMTP id g13mr10590345pgk.26.1591062668254; Mon, 01 Jun 2020 18:51:08 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id d2sm604921pfc.7.2020.06.01.18.51.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 18:51:07 -0700 (PDT) References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> From: OKUMURA Shinji To: SIPCORE Cc: "Dale R. Worley" , Roman Shpount Message-ID: Date: Tue, 2 Jun 2020 10:51:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 01:51:10 -0000 Roman, Three(b, c, d) of my suggestions are the same as RFC4028. The last one(a) also does not violate the RFC4028. Therefore, this situation can occur even with the current regulations. And rules regarding Min-SE have not changed. Even without using the 422 response, proxies can indicate the desired Min-SE to a UAS. So if there is a security risk, it means that the RFC4028 has the same risk. Regards, Shinji On 2020/06/02 2:02, Roman Shpount wrote: >   Shinji, > > The main purposes of session timers is to allow SIP proxies to maintain dialog state for billing and other purposes. Proxies are the main agents that insert Session-Expires header. In most cases there is no reason for UA to use session timers since they can normally monitor call presence without it. Your proposal makes the most common use case for session timers impossible. > > Min-SE exists mainly for the purpose of preventing badly behaving proxies or UA from overload proxies on the call path or UAS. Not allowing proxy to send 422 creates a big security risk. > > My general attitude is that parallel forking is broken for a lot of use cases anyway, so it should be avoided. I do not think a lot of production deployments are actually use parallel forking. Most of the UA would not handle multiple 200 OK responses that can be created as a result of parallel fork. Session timers are, on the other hand, are used a lot. So I would prefer to live with broken or under-specified parallel forking vs breaking session timers. > > Thank You, > _____________ > Roman Shpount > > > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji > wrote: > > Hi, > > I've not intended to suggest a common solution to the fork-issue. I am interested in how the fork does not happen. It is related to the behavior of proxies and a UAS in the 1st phase that you mention. My suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as possible. > > Considering backward compatibility, rules are as follows. > > a) A UAC and proxies should not insert a Session-Expires header. > b) A UAC and proxies may insert a Min-SE header or increase the value of it. > c) A UAS may insert a Session-Expires header into a 200 response. > d) A proxy may insert a Session-Expires header into a 200 response, but must not modify it. > > Of course legacy proxies will return 422, but this is unavoidable. > In that case, the following rule may be useful. > > e) If a proxy increases the value of a Min-SE header and it becomes greater than the value of a Session-Expires header, then a proxy should increase the value of a Session-Expires header to the value of a Min-SE header. > > However, this rule can be problematic in terms of backward compatibility. > > Shinji > > On 2020/05/29 11:30, Dale R. Worley wrote: > > OKUMURA Shinji > writes: > >> As you point out, the other responses(407, 420, ...) cause the same problem. > >> But session-timer is essentially a kind of pre-condition, so I'd like > >> to avoid incoming calls to fail because of it. And I'd like to sort > >> out also the rules in early dialog. > > > >> On 2020/05/27 19:16, Christer Holmberg wrote: > >>> A proxy rejecting a request is not unique to the session-timer. > >>> > >>> If Alice receives a 422 she can send a CANCEL (if other early dialogs > >>> have been established), and then a new initial INVITE. > > > > (This has a larger scope than just session-timers.) > > > > I don't know if the above writers intended this point, but reading what > > they have said suggests to me this possible behavior for proxies (which > > I don't recall seeing suggested): > > > > Note that 422 is one of a number of "pre-condition failure" response > > codes.  Those have the properties (1) when they are generated, they are > > generated nearly immediately from the INVITE, and (2) the UAC can adjust > > the INVITE to prevent them. > > > > Suppose that if a proxy receives one of these "pre-condition failure" > > responses, it immediately (or with short delay on a human scale) cancels > > all remaining forks of the transaction and returns the failure response > > upstream. > > > > The effect is to split the "early dialog" phase into two sub-phases, (1) > > a very short phase where the forking of the INVITE effectively probes > > for proxies and UASs that object to the the INVITE for "pre-condition" > > reasons, and (2) a longer phase which resembles the current early dialog > > phase. > > > > There are probably refinements needed to make this work in all cases. > > > > Dale > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 1 23:17:09 2020 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 84BF53A07FB for ; Mon, 1 Jun 2020 23:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JuugHjKMsDRB for ; Mon, 1 Jun 2020 23:17:05 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 BACF23A07F8 for ; Mon, 1 Jun 2020 23:17:05 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id s13so6644otd.7 for ; Mon, 01 Jun 2020 23:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5kkC3P5ZBx+mRVl1IwjzQI6CHz2ytrS57s/ATOKb+O4=; b=mfN+LmcD/JTqN0UD6/pTUmKp8Kyl9be0vpb2aEchJiI52ML/GE2wiSnAQhkccmAKKA G12Zm1HxJvWXKrQx0grD5oAps41XQN2JtsgRKKdTzrbPiGDSXbDq2FsejFkXnDx0sy1R UkK7v9UVyVrO+U+yBjBADXocipOr3ANVAG0TF2IkEE5mXhI9yTqloa1Yl8qxiX/Wxpyy TsZkk1OetY4HTdOTDqi+p7c1TwDQewdoBZIkTwB6FL7H2P3ohzRoc5ng6ylPBoTEyaar k+uFSjPqNeh4HTaCCL6yF18FPKCqsr/xIqjrq7Ex1jwOIAMiv579EjJ+z1UI7Stb3FE8 Sd2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5kkC3P5ZBx+mRVl1IwjzQI6CHz2ytrS57s/ATOKb+O4=; b=m/SdQr3WZcFk6H3XEtDwT/rDJnjWNrfzOZ6EdvBM5iupCefb8FUalPaMZJKP27pL2e okGAKCS8EU+D9fJ3HSL8GgrigXoOuysw4fOVWvZeNJtTLW6Y9X3B+TZsVX3vhfsHke+1 PGVeiXl+PirgioYqZoNN2uzF34c5uBibAlSWxYOg4+N+um+mSdMSYOwBnCBY9D9ksVq5 tMiURlhj9tDvunkShBQbudzBs2vmQJah0viVtKjFkUVmIvdqcJrrKenmsccOThZfCV8m l+Hdo+iNWcWSa2Wy+RejnaMI3eqadVUuMp81FhnT/i/uOoPmsY3wNCvNnIcq6Y8e5HkI tGfw== X-Gm-Message-State: AOAM530yshw5R44DSfnIlzRBlqJnYPiVHoD8u/0C38QUryMiBb0lmuuv UAW3StquhJgLphi/B9WPtyUmZFzZD38= X-Google-Smtp-Source: ABdhPJzyL3XXdl8Vf8YCXzU1QswFZcUCGd/gsad7uMIOJMHBBb35ZLHd5Jjuuc9jiwSgzl3i8/CxuQ== X-Received: by 2002:a9d:6d19:: with SMTP id o25mr179793otp.354.1591078624449; Mon, 01 Jun 2020 23:17:04 -0700 (PDT) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com. [209.85.210.50]) by smtp.gmail.com with ESMTPSA id p4sm428429oti.59.2020.06.01.23.17.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 23:17:03 -0700 (PDT) Received: by mail-ot1-f50.google.com with SMTP id b18so10058112oti.1 for ; Mon, 01 Jun 2020 23:17:03 -0700 (PDT) X-Received: by 2002:a9d:5d08:: with SMTP id b8mr19106919oti.19.1591078622794; Mon, 01 Jun 2020 23:17:02 -0700 (PDT) MIME-Version: 1.0 References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Tue, 2 Jun 2020 02:16:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , "Dale R. Worley" Content-Type: multipart/alternative; boundary="0000000000001f17fd05a713dcc9" Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 06:17:08 -0000 --0000000000001f17fd05a713dcc9 Content-Type: text/plain; charset="UTF-8" Shinji, I have an issue with two of your proposals: 1. Proxy cannot add Session-Timer 2. Proxy cannot generate 422 response Both break session timer as it is implemented and used now. Best, _____________ Roman Shpount On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji wrote: > Roman, > > Three(b, c, d) of my suggestions are the same as RFC4028. The last one(a) > also does not violate the RFC4028. Therefore, this situation can occur even > with the current regulations. > > And rules regarding Min-SE have not changed. Even without using the 422 > response, proxies can indicate the desired Min-SE to a UAS. So if there is > a security risk, it means that the RFC4028 has the same risk. > > Regards, > > Shinji > > On 2020/06/02 2:02, Roman Shpount wrote: > > Shinji, > > > > The main purposes of session timers is to allow SIP proxies to maintain > dialog state for billing and other purposes. Proxies are the main agents > that insert Session-Expires header. In most cases there is no reason for UA > to use session timers since they can normally monitor call presence without > it. Your proposal makes the most common use case for session timers > impossible. > > > > Min-SE exists mainly for the purpose of preventing badly behaving > proxies or UA from overload proxies on the call path or UAS. Not allowing > proxy to send 422 creates a big security risk. > > > > My general attitude is that parallel forking is broken for a lot of use > cases anyway, so it should be avoided. I do not think a lot of production > deployments are actually use parallel forking. Most of the UA would not > handle multiple 200 OK responses that can be created as a result of > parallel fork. Session timers are, on the other hand, are used a lot. So I > would prefer to live with broken or under-specified parallel forking vs > breaking session timers. > > > > Thank You, > > _____________ > > Roman Shpount > > > > > > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji > wrote: > > > > Hi, > > > > I've not intended to suggest a common solution to the fork-issue. I > am interested in how the fork does not happen. It is related to the > behavior of proxies and a UAS in the 1st phase that you mention. My > suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as > possible. > > > > Considering backward compatibility, rules are as follows. > > > > a) A UAC and proxies should not insert a Session-Expires header. > > b) A UAC and proxies may insert a Min-SE header or increase the > value of it. > > c) A UAS may insert a Session-Expires header into a 200 response. > > d) A proxy may insert a Session-Expires header into a 200 response, > but must not modify it. > > > > Of course legacy proxies will return 422, but this is unavoidable. > > In that case, the following rule may be useful. > > > > e) If a proxy increases the value of a Min-SE header and it becomes > greater than the value of a Session-Expires header, then a proxy should > increase the value of a Session-Expires header to the value of a Min-SE > header. > > > > However, this rule can be problematic in terms of backward > compatibility. > > > > Shinji > > > > On 2020/05/29 11:30, Dale R. Worley wrote: > > > OKUMURA Shinji ietf.shinji@gmail.com>> writes: > > >> As you point out, the other responses(407, 420, ...) cause the > same problem. > > >> But session-timer is essentially a kind of pre-condition, so I'd > like > > >> to avoid incoming calls to fail because of it. And I'd like to > sort > > >> out also the rules in early dialog. > > > > > >> On 2020/05/27 19:16, Christer Holmberg wrote: > > >>> A proxy rejecting a request is not unique to the session-timer. > > >>> > > >>> If Alice receives a 422 she can send a CANCEL (if other early > dialogs > > >>> have been established), and then a new initial INVITE. > > > > > > (This has a larger scope than just session-timers.) > > > > > > I don't know if the above writers intended this point, but > reading what > > > they have said suggests to me this possible behavior for proxies > (which > > > I don't recall seeing suggested): > > > > > > Note that 422 is one of a number of "pre-condition failure" > response > > > codes. Those have the properties (1) when they are generated, > they are > > > generated nearly immediately from the INVITE, and (2) the UAC can > adjust > > > the INVITE to prevent them. > > > > > > Suppose that if a proxy receives one of these "pre-condition > failure" > > > responses, it immediately (or with short delay on a human scale) > cancels > > > all remaining forks of the transaction and returns the failure > response > > > upstream. > > > > > > The effect is to split the "early dialog" phase into two > sub-phases, (1) > > > a very short phase where the forking of the INVITE effectively > probes > > > for proxies and UASs that object to the the INVITE for > "pre-condition" > > > reasons, and (2) a longer phase which resembles the current early > dialog > > > phase. > > > > > > There are probably refinements needed to make this work in all > cases. > > > > > > Dale > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --0000000000001f17fd05a713dcc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

I have an issue with two of your proposals:

1. Proxy cannot add Session-Timer
2. Proxy cannot generate 422= response

Both break session timer as it is implem= ented and used now.

Best,=C2=A0
<= div>
_____________
Roman Shpount


On Mon, Jun 1, 2= 020 at 9:51 PM OKUMURA Shinji <= ietf.shinji@gmail.com> wrote:
Roman,

Three(b, c, d) of my suggestions are the same as RFC4028. The last one(a) a= lso does not violate the RFC4028. Therefore, this situation can occur even = with the current regulations.

And rules regarding Min-SE have not changed. Even without using the 422 res= ponse, proxies can indicate the desired Min-SE to a UAS. So if there is a s= ecurity risk, it means that the RFC4028 has the same risk.

Regards,

Shinji

On 2020/06/02 2:02, Roman Shpount wrote:
>=C2=A0 =C2=A0 Shinji,
>
> The main purposes of session timers is to allow SIP proxies to maintai= n dialog state for billing and other purposes. Proxies are the main agents = that insert Session-Expires header. In most cases there is no reason for UA= to use session timers since they can normally monitor call presence withou= t it. Your proposal makes the=C2=A0most common use case for session timers = impossible.
>
> Min-SE exists mainly for the purpose of=C2=A0preventing badly behaving= proxies or UA from overload proxies on the call path or UAS. Not allowing = proxy to send 422 creates a big security risk.
>
> My general attitude is that parallel forking is broken for a lot of us= e cases anyway, so it should be avoided. I do not think a lot of production= deployments are actually use=C2=A0parallel forking. Most of the UA would n= ot handle multiple 200 OK responses that can be created as a result of para= llel fork. Session timers are, on the=C2=A0other hand, are used a lot. So I= would prefer to live with broken or under-specified parallel forking vs br= eaking session timers.
>
> Thank You,
> _____________
> Roman Shpount
>
>
> On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji <ietf.shinji@gmail.com <mailto= :ietf.shinji@gma= il.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0I've not intended to suggest a common solution = to the fork-issue. I am interested in how the fork does not happen. It is r= elated to the behavior of proxies and a UAS in the 1st phase that you menti= on. My suggestion is that a UAS and proxies SHOULD avoid returning 422 as m= uch as possible.
>
>=C2=A0 =C2=A0 =C2=A0Considering backward compatibility, rules are as fo= llows.
>
>=C2=A0 =C2=A0 =C2=A0a) A UAC and proxies should not insert a Session-Ex= pires header.
>=C2=A0 =C2=A0 =C2=A0b) A UAC and proxies may insert a Min-SE header or = increase the value of it.
>=C2=A0 =C2=A0 =C2=A0c) A UAS may insert a Session-Expires header into a= 200 response.
>=C2=A0 =C2=A0 =C2=A0d) A proxy may insert a Session-Expires header into= a 200 response, but must not modify it.
>
>=C2=A0 =C2=A0 =C2=A0Of course legacy proxies will return 422, but this = is unavoidable.
>=C2=A0 =C2=A0 =C2=A0In that case, the following rule may be useful.
>
>=C2=A0 =C2=A0 =C2=A0e) If a proxy increases the value of a Min-SE heade= r and it becomes greater than the value of a Session-Expires header, then a= proxy should increase the value of a Session-Expires header to the value o= f a Min-SE header.
>
>=C2=A0 =C2=A0 =C2=A0However, this rule can be problematic in terms of b= ackward compatibility.
>
>=C2=A0 =C2=A0 =C2=A0Shinji
>
>=C2=A0 =C2=A0 =C2=A0On 2020/05/29 11:30, Dale R. Worley wrote:
>=C2=A0 =C2=A0 =C2=A0 > OKUMURA Shinji <ietf.shinji@gmail.com <mailto:ietf.shinji@gmail.com= >> writes:
>=C2=A0 =C2=A0 =C2=A0 >> As you point out, the other responses(407= , 420, ...) cause the same problem.
>=C2=A0 =C2=A0 =C2=A0 >> But session-timer is essentially a kind o= f pre-condition, so I'd like
>=C2=A0 =C2=A0 =C2=A0 >> to avoid incoming calls to fail because o= f it. And I'd like to sort
>=C2=A0 =C2=A0 =C2=A0 >> out also the rules in early dialog.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >> On 2020/05/27 19:16, Christer Holmberg wr= ote:
>=C2=A0 =C2=A0 =C2=A0 >>> A proxy rejecting a request is not un= ique to the session-timer.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> If Alice receives a 422 she can send = a CANCEL (if other early dialogs
>=C2=A0 =C2=A0 =C2=A0 >>> have been established), and then a ne= w initial INVITE.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > (This has a larger scope than just session-ti= mers.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I don't know if the above writers intende= d this point, but reading what
>=C2=A0 =C2=A0 =C2=A0 > they have said suggests to me this possible b= ehavior for proxies (which
>=C2=A0 =C2=A0 =C2=A0 > I don't recall seeing suggested):
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Note that 422 is one of a number of "pre= -condition failure" response
>=C2=A0 =C2=A0 =C2=A0 > codes.=C2=A0 Those have the properties (1) wh= en they are generated, they are
>=C2=A0 =C2=A0 =C2=A0 > generated nearly immediately from the INVITE,= and (2) the UAC can adjust
>=C2=A0 =C2=A0 =C2=A0 > the INVITE to prevent them.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Suppose that if a proxy receives one of these= "pre-condition failure"
>=C2=A0 =C2=A0 =C2=A0 > responses, it immediately (or with short dela= y on a human scale) cancels
>=C2=A0 =C2=A0 =C2=A0 > all remaining forks of the transaction and re= turns the failure response
>=C2=A0 =C2=A0 =C2=A0 > upstream.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The effect is to split the "early dialog= " phase into two sub-phases, (1)
>=C2=A0 =C2=A0 =C2=A0 > a very short phase where the forking of the I= NVITE effectively probes
>=C2=A0 =C2=A0 =C2=A0 > for proxies and UASs that object to the the I= NVITE for "pre-condition"
>=C2=A0 =C2=A0 =C2=A0 > reasons, and (2) a longer phase which resembl= es the current early dialog
>=C2=A0 =C2=A0 =C2=A0 > phase.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > There are probably refinements needed to make= this work in all cases.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Dale
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>
--0000000000001f17fd05a713dcc9-- From nobody Tue Jun 2 00:49:10 2020 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 334BC3A08FF for ; Tue, 2 Jun 2020 00:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaHC5OrFJvLN for ; Tue, 2 Jun 2020 00:49:06 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 86FF53A08FE for ; Tue, 2 Jun 2020 00:49:06 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id y11so1006829plt.12 for ; Tue, 02 Jun 2020 00:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=f/H/Uphn57u+2yVTpVRoJBUudppuBZEaIhCDZlVeFYs=; b=cekjs62r4DWn2D6tXL/wRpr/a3gici1EjCgQaO1uqWZ2QJPrE4zGrs6yTweUjG+ttW KMIJztaOjl2V6DC2GC0G1+oZbBmPNVrPfCxmDfJLhnBqJ7YlcILn/xgE8ITizIuUvbXC OoSmckXaepi+hFgVvhqcqf27F4fD3E5H72zpbz5ZRQc9+Wr62uMh6o+eTg5JvHtlVv2u 1HdlenoijutgRO5ob8XpUM04ZuU3X1SiuF7HBRSzpCCkjdbPRrfXaElyDmkqUnTzb+oY fwQ0RR9JzNHSt++46lVz0akBPJSR6OTJnk6Q3xIJYAGvLQxzjVkNU+MU5dqPRtC6v/OI 8uUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=f/H/Uphn57u+2yVTpVRoJBUudppuBZEaIhCDZlVeFYs=; b=txsJbKxJnw/KcCzvtRZzTwyXUX1KKW5lYyLq0/WL4FQLD3lK5Pr7s6Lmy0dL9ke7x4 OlXcnHQz0fOzt/uled3m51YgORMlCBxwEbFKZi17HvdIdMiv16sigq5lXV5clMWm1gzb 5sTtKIlqDugyOuL83GIm2JY6aYDL5A4DqSmlJu5NkuedpYTlG8AnUl6aplmQLupxBiIX aNhqveqCxr+izBRayetesjq8Fn1IJZta+OzBoULA8KSg+xB1vH2V6LXwDYcNIGcZWhMm isE7+Agrd996xgQKHeZaUdo99wBIfHoPtAFz86jyJ9du54IzhL4Yptz6n0ukJDn0tlmS mqGw== X-Gm-Message-State: AOAM532ee4imgUzRPnm9/zgY24IDfXAtlmAFtJF2Rn3O7zqJZ1se2Lrb sJPfuveuNVeAXwEsaM9dvvOuodaf X-Google-Smtp-Source: ABdhPJxKZtw0tr503jEliVg4QYf7wJ33xwOoxJNO7iUF9HKxFAok2ayzBwZu+hx1927FOhvq+KAEuw== X-Received: by 2002:a17:90a:46ce:: with SMTP id x14mr3966328pjg.121.1591084145912; Tue, 02 Jun 2020 00:49:05 -0700 (PDT) Received: from [192.168.1.127] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id bu7sm1529776pjb.41.2020.06.02.00.49.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 00:49:05 -0700 (PDT) To: SIPCORE Cc: Roman Shpount , "Dale R. Worley" References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> From: OKUMURA Shinji Message-ID: <0734a24f-a069-1889-b4e0-bc27a39280f5@gmail.com> Date: Tue, 2 Jun 2020 16:49:02 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 07:49:08 -0000 Roman, > I have an issue with two of your proposals: > > 1. Proxy cannot add Session-Timer > 2. Proxy cannot generate 422 response I'm not suggesting that proxy cannot add Session-Timer. The use of "should not" may not have been appropriate. I think it is a requirement levels issue. How about rephrasing it as follows? "A UAC and proxies MAY add a Session-Expires header, but it is NOT RECOMMENDED." Obviously, legacy proxies add a Session-Expires header, so another proxy need to be prepared for that. Shinji On 2020/06/02 15:16, Roman Shpount wrote: > Shinji, > > I have an issue with two of your proposals: > > 1. Proxy cannot add Session-Timer > 2. Proxy cannot generate 422 response > > Both break session timer as it is implemented and used now. > > Best, > _____________ > Roman Shpount > > > On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji > wrote: > > Roman, > > Three(b, c, d) of my suggestions are the same as RFC4028. The last one(a) also does not violate the RFC4028. Therefore, this situation can occur even with the current regulations. > > And rules regarding Min-SE have not changed. Even without using the 422 response, proxies can indicate the desired Min-SE to a UAS. So if there is a security risk, it means that the RFC4028 has the same risk. > > Regards, > > Shinji > > On 2020/06/02 2:02, Roman Shpount wrote: > >    Shinji, > > > > The main purposes of session timers is to allow SIP proxies to maintain dialog state for billing and other purposes. Proxies are the main agents that insert Session-Expires header. In most cases there is no reason for UA to use session timers since they can normally monitor call presence without it. Your proposal makes the most common use case for session timers impossible. > > > > Min-SE exists mainly for the purpose of preventing badly behaving proxies or UA from overload proxies on the call path or UAS. Not allowing proxy to send 422 creates a big security risk. > > > > My general attitude is that parallel forking is broken for a lot of use cases anyway, so it should be avoided. I do not think a lot of production deployments are actually use parallel forking. Most of the UA would not handle multiple 200 OK responses that can be created as a result of parallel fork. Session timers are, on the other hand, are used a lot. So I would prefer to live with broken or under-specified parallel forking vs breaking session timers. > > > > Thank You, > > _____________ > > Roman Shpount > > > > > > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji >> wrote: > > > >     Hi, > > > >     I've not intended to suggest a common solution to the fork-issue. I am interested in how the fork does not happen. It is related to the behavior of proxies and a UAS in the 1st phase that you mention. My suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as possible. > > > >     Considering backward compatibility, rules are as follows. > > > >     a) A UAC and proxies should not insert a Session-Expires header. > >     b) A UAC and proxies may insert a Min-SE header or increase the value of it. > >     c) A UAS may insert a Session-Expires header into a 200 response. > >     d) A proxy may insert a Session-Expires header into a 200 response, but must not modify it. > > > >     Of course legacy proxies will return 422, but this is unavoidable. > >     In that case, the following rule may be useful. > > > >     e) If a proxy increases the value of a Min-SE header and it becomes greater than the value of a Session-Expires header, then a proxy should increase the value of a Session-Expires header to the value of a Min-SE header. > > > >     However, this rule can be problematic in terms of backward compatibility. > > > >     Shinji > > > >     On 2020/05/29 11:30, Dale R. Worley wrote: > >      > OKUMURA Shinji >> writes: > >      >> As you point out, the other responses(407, 420, ...) cause the same problem. > >      >> But session-timer is essentially a kind of pre-condition, so I'd like > >      >> to avoid incoming calls to fail because of it. And I'd like to sort > >      >> out also the rules in early dialog. > >      > > >      >> On 2020/05/27 19:16, Christer Holmberg wrote: > >      >>> A proxy rejecting a request is not unique to the session-timer. > >      >>> > >      >>> If Alice receives a 422 she can send a CANCEL (if other early dialogs > >      >>> have been established), and then a new initial INVITE. > >      > > >      > (This has a larger scope than just session-timers.) > >      > > >      > I don't know if the above writers intended this point, but reading what > >      > they have said suggests to me this possible behavior for proxies (which > >      > I don't recall seeing suggested): > >      > > >      > Note that 422 is one of a number of "pre-condition failure" response > >      > codes.  Those have the properties (1) when they are generated, they are > >      > generated nearly immediately from the INVITE, and (2) the UAC can adjust > >      > the INVITE to prevent them. > >      > > >      > Suppose that if a proxy receives one of these "pre-condition failure" > >      > responses, it immediately (or with short delay on a human scale) cancels > >      > all remaining forks of the transaction and returns the failure response > >      > upstream. > >      > > >      > The effect is to split the "early dialog" phase into two sub-phases, (1) > >      > a very short phase where the forking of the INVITE effectively probes > >      > for proxies and UASs that object to the the INVITE for "pre-condition" > >      > reasons, and (2) a longer phase which resembles the current early dialog > >      > phase. > >      > > >      > There are probably refinements needed to make this work in all cases. > >      > > >      > Dale > >      > > > > >     _______________________________________________ > >     sipcore mailing list > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Tue Jun 2 01:18:44 2020 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 B3F0D3A0993 for ; Tue, 2 Jun 2020 01:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 y8y1xyiz1CfS for ; Tue, 2 Jun 2020 01:18:39 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 32F133A0971 for ; Tue, 2 Jun 2020 01:18:39 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id s21so2567710oic.9 for ; Tue, 02 Jun 2020 01:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5xfxjcLyY6/nN32kxazJrNmClDdJlOcmSOyPL4MnD2c=; b=SEqjSFVrVtOysH80iHnqA6I4GrAZGcwYz3cWg3Fid6r60/r2IdDHDRIutA5FNHZ8eY xaNgT3PfFyWRXgDWxX8I8eH9p1Zhp/NUEA2lvU0RJiE9nYoAFo4RdMgpKdhpqdgGG6Zy AVTU0cXDN7C0TBiTmSHf0ofwJSL5GR1eeGpzTovJD5dXbwDbeIfFP3nfIw0L+dxdDqRr YKRlP9mWoSkZ3gKtIsdip/EjFZJ68Q9HyqvhosoK7DceI8KbSH2K31uwY8DRUjGFzi1E zbm59T1ILhGZtXVu0Ec3xYFqtOP1VRvZjdW1FO9lG2dZnh/CFgTmKThAA0uSFU4umdBY 2VBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5xfxjcLyY6/nN32kxazJrNmClDdJlOcmSOyPL4MnD2c=; b=nulhYz/guwAjAJPt7vB05M2WtL9q46byLgsOLdjBoIdikzPNVZ9v9c9qQTpJnkpVkt mytpR0cG1xf3Dk/++K6sHP81fc/fz73kLKvrm3HUj2JKceiW4GXbab/YRhGjUfae3lh6 xoi2+o7tZjIxKBlghS9GQ23FZ0VpLQ+GxvfwJZLXk3uSmZpvcoMQfapPVswTltL3rLhG zLA6UdvyEBHFJOTELuO9pYtJP2u7MpWkFoNfzh9TpPWHKt9D3LF0s3O3gM8qUKTWMwz/ Kq5JPIfynGvFTsA1nyyZY3KpFrgyM8Jpc1GD4L8Ok4AiAV4xIFoAo9wKbnC+vaDqlEm+ XOmg== X-Gm-Message-State: AOAM530WugClCrSfApeD1ZMjA79gk/c4zLY/dbzkHfeMxjqaHon5Ohai OI+k47oq1MLxjC5TyS6qm9IquyqtL8k= X-Google-Smtp-Source: ABdhPJxIUYFKfeWyFBTh2RcUnAihNojg92DknjkPY7+ihHNmthij2618BAeYNNYw+4svna3/J14UtQ== X-Received: by 2002:aca:1e0f:: with SMTP id m15mr2246257oic.23.1591085918254; Tue, 02 Jun 2020 01:18:38 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id 8sm552633oot.0.2020.06.02.01.18.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 01:18:37 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id h7so10289977otr.3 for ; Tue, 02 Jun 2020 01:18:36 -0700 (PDT) X-Received: by 2002:a9d:604e:: with SMTP id v14mr8108691otj.39.1591085916228; Tue, 02 Jun 2020 01:18:36 -0700 (PDT) MIME-Version: 1.0 References: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> <0734a24f-a069-1889-b4e0-bc27a39280f5@gmail.com> In-Reply-To: <0734a24f-a069-1889-b4e0-bc27a39280f5@gmail.com> From: Roman Shpount Date: Tue, 2 Jun 2020 04:18:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , "Dale R. Worley" Content-Type: multipart/alternative; boundary="000000000000d810e905a7158e74" Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 08:18:42 -0000 --000000000000d810e905a7158e74 Content-Type: text/plain; charset="UTF-8" Shinji, Proxies adding Session-Expires header is the primary reason for existence of SIP Session Timers. This header is added almost exclusively by proxies in order to maintain dialog state. Because of this, your proposal makes no sense to me. As I have said, I would much rather see parallel forking dropped from supported scenarios. _____________ Roman Shpount On Tue, Jun 2, 2020 at 3:49 AM OKUMURA Shinji wrote: > Roman, > > > I have an issue with two of your proposals: > > > > 1. Proxy cannot add Session-Timer > > 2. Proxy cannot generate 422 response > > I'm not suggesting that proxy cannot add Session-Timer. The use of "should > not" may not have been appropriate. I think it is a requirement levels > issue. > How about rephrasing it as follows? > > "A UAC and proxies MAY add a Session-Expires header, but it is NOT > RECOMMENDED." > > Obviously, legacy proxies add a Session-Expires header, so another proxy > need to be prepared for that. > > Shinji > > On 2020/06/02 15:16, Roman Shpount wrote: > > Shinji, > > > > I have an issue with two of your proposals: > > > > 1. Proxy cannot add Session-Timer > > 2. Proxy cannot generate 422 response > > > > Both break session timer as it is implemented and used now. > > > > Best, > > _____________ > > Roman Shpount > > > > > > On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji > wrote: > > > > Roman, > > > > Three(b, c, d) of my suggestions are the same as RFC4028. The last > one(a) also does not violate the RFC4028. Therefore, this situation can > occur even with the current regulations. > > > > And rules regarding Min-SE have not changed. Even without using the > 422 response, proxies can indicate the desired Min-SE to a UAS. So if there > is a security risk, it means that the RFC4028 has the same risk. > > > > Regards, > > > > Shinji > > > > On 2020/06/02 2:02, Roman Shpount wrote: > > > Shinji, > > > > > > The main purposes of session timers is to allow SIP proxies to > maintain dialog state for billing and other purposes. Proxies are the main > agents that insert Session-Expires header. In most cases there is no reason > for UA to use session timers since they can normally monitor call presence > without it. Your proposal makes the most common use case for session timers > impossible. > > > > > > Min-SE exists mainly for the purpose of preventing badly behaving > proxies or UA from overload proxies on the call path or UAS. Not allowing > proxy to send 422 creates a big security risk. > > > > > > My general attitude is that parallel forking is broken for a lot > of use cases anyway, so it should be avoided. I do not think a lot of > production deployments are actually use parallel forking. Most of the UA > would not handle multiple 200 OK responses that can be created as a result > of parallel fork. Session timers are, on the other hand, are used a lot. So > I would prefer to live with broken or under-specified parallel forking vs > breaking session timers. > > > > > > Thank You, > > > _____________ > > > Roman Shpount > > > > > > > > > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji < > ietf.shinji@gmail.com ietf.shinji@gmail.com >> wrote: > > > > > > Hi, > > > > > > I've not intended to suggest a common solution to the > fork-issue. I am interested in how the fork does not happen. It is related > to the behavior of proxies and a UAS in the 1st phase that you mention. My > suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as > possible. > > > > > > Considering backward compatibility, rules are as follows. > > > > > > a) A UAC and proxies should not insert a Session-Expires > header. > > > b) A UAC and proxies may insert a Min-SE header or increase > the value of it. > > > c) A UAS may insert a Session-Expires header into a 200 > response. > > > d) A proxy may insert a Session-Expires header into a 200 > response, but must not modify it. > > > > > > Of course legacy proxies will return 422, but this is > unavoidable. > > > In that case, the following rule may be useful. > > > > > > e) If a proxy increases the value of a Min-SE header and it > becomes greater than the value of a Session-Expires header, then a proxy > should increase the value of a Session-Expires header to the value of a > Min-SE header. > > > > > > However, this rule can be problematic in terms of backward > compatibility. > > > > > > Shinji > > > > > > On 2020/05/29 11:30, Dale R. Worley wrote: > > > > OKUMURA Shinji ietf.shinji@gmail.com> ietf.shinji@gmail.com>>> writes: > > > >> As you point out, the other responses(407, 420, ...) > cause the same problem. > > > >> But session-timer is essentially a kind of pre-condition, > so I'd like > > > >> to avoid incoming calls to fail because of it. And I'd > like to sort > > > >> out also the rules in early dialog. > > > > > > > >> On 2020/05/27 19:16, Christer Holmberg wrote: > > > >>> A proxy rejecting a request is not unique to the > session-timer. > > > >>> > > > >>> If Alice receives a 422 she can send a CANCEL (if other > early dialogs > > > >>> have been established), and then a new initial INVITE. > > > > > > > > (This has a larger scope than just session-timers.) > > > > > > > > I don't know if the above writers intended this point, but > reading what > > > > they have said suggests to me this possible behavior for > proxies (which > > > > I don't recall seeing suggested): > > > > > > > > Note that 422 is one of a number of "pre-condition > failure" response > > > > codes. Those have the properties (1) when they are > generated, they are > > > > generated nearly immediately from the INVITE, and (2) the > UAC can adjust > > > > the INVITE to prevent them. > > > > > > > > Suppose that if a proxy receives one of these > "pre-condition failure" > > > > responses, it immediately (or with short delay on a human > scale) cancels > > > > all remaining forks of the transaction and returns the > failure response > > > > upstream. > > > > > > > > The effect is to split the "early dialog" phase into two > sub-phases, (1) > > > > a very short phase where the forking of the INVITE > effectively probes > > > > for proxies and UASs that object to the the INVITE for > "pre-condition" > > > > reasons, and (2) a longer phase which resembles the > current early dialog > > > > phase. > > > > > > > > There are probably refinements needed to make this work in > all cases. > > > > > > > > Dale > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > --000000000000d810e905a7158e74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

Proxies add= ing Session-Expires header is the primary reason for existence of SIP Sessi= on Timers. This header is added almost exclusively=C2=A0by proxies in order= to maintain dialog state.

Because of this, your proposal makes= no sense to me.=C2=A0

As I have said, I wo= uld much rather see parallel forking dropped from supported scenarios.
<= div>
_____________
Roman Shpount


On Tu= e, Jun 2, 2020 at 3:49 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
Roman,

> I have an issue with two of your proposals:
>
> 1. Proxy cannot add Session-Timer
> 2. Proxy cannot generate 422 response

I'm not suggesting that proxy cannot add Session-Timer. The use of &quo= t;should not" may not have been appropriate. I think it is a requireme= nt levels issue.
How about rephrasing it as follows?

"A UAC and proxies MAY add a Session-Expires header, but it is NOT REC= OMMENDED."

Obviously, legacy proxies add a Session-Expires header, so another proxy ne= ed to be prepared for that.

Shinji

On 2020/06/02 15:16, Roman Shpount wrote:
> Shinji,
>
> I have an issue with two of your proposals:
>
> 1. Proxy cannot add Session-Timer
> 2. Proxy cannot generate 422 response
>
> Both break session timer as it is implemented and used now.
>
> Best,
> _____________
> Roman Shpount
>
>
> On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji <ietf.shinji@gmail.com <mailto= :ietf.shinji@gma= il.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Roman,
>
>=C2=A0 =C2=A0 =C2=A0Three(b, c, d) of my suggestions are the same as RF= C4028. The last one(a) also does not violate the RFC4028. Therefore, this s= ituation can occur even with the current regulations.
>
>=C2=A0 =C2=A0 =C2=A0And rules regarding Min-SE have not changed. Even w= ithout using the 422 response, proxies can indicate the desired Min-SE to a= UAS. So if there is a security risk, it means that the RFC4028 has the sam= e risk.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0Shinji
>
>=C2=A0 =C2=A0 =C2=A0On 2020/06/02 2:02, Roman Shpount wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Shinji,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The main purposes of session timers is to all= ow SIP proxies to maintain dialog state for billing and other purposes. Pro= xies are the main agents that insert Session-Expires header. In most cases = there is no reason for UA to use session timers since they can normally mon= itor call presence without it. Your proposal makes the=C2=A0most common use= case for session timers impossible.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Min-SE exists mainly for the purpose of=C2=A0= preventing badly behaving proxies or UA from overload proxies on the call p= ath or UAS. Not allowing proxy to send 422 creates a big security risk.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > My general attitude is that parallel forking = is broken for a lot of use cases anyway, so it should be avoided. I do not = think a lot of production deployments are actually use=C2=A0parallel forkin= g. Most of the UA would not handle multiple 200 OK responses that can be cr= eated as a result of parallel fork. Session timers are, on the=C2=A0other h= and, are used a lot. So I would prefer to live with broken or under-specifi= ed parallel forking vs breaking session timers.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Thank You,
>=C2=A0 =C2=A0 =C2=A0 > _____________
>=C2=A0 =C2=A0 =C2=A0 > Roman Shpount
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji= <ietf.shinji= @gmail.com <mailto:ietf.shinji@gmail.com> <mailto:ietf.shinji@gmail.com <mailto:<= a href=3D"mailto:ietf.shinji@gmail.com" target=3D"_blank">ietf.shinji@gmail= .com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hi,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I've not intended to s= uggest a common solution to the fork-issue. I am interested in how the fork= does not happen. It is related to the behavior of proxies and a UAS in the= 1st phase that you mention. My suggestion is that a UAS and proxies SHOULD= avoid returning 422 as much as possible.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Considering backward compa= tibility, rules are as follows.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a) A UAC and proxies shoul= d not insert a Session-Expires header.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b) A UAC and proxies may i= nsert a Min-SE header or increase the value of it.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c) A UAS may insert a Sess= ion-Expires header into a 200 response.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d) A proxy may insert a Se= ssion-Expires header into a 200 response, but must not modify it.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Of course legacy proxies w= ill return 422, but this is unavoidable.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0In that case, the followin= g rule may be useful.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0e) If a proxy increases th= e value of a Min-SE header and it becomes greater than the value of a Sessi= on-Expires header, then a proxy should increase the value of a Session-Expi= res header to the value of a Min-SE header.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0However, this rule can be = problematic in terms of backward compatibility.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Shinji
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 2020/05/29 11:30, Dale = R. Worley wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > OKUMURA Shinji <<= a href=3D"mailto:ietf.shinji@gmail.com" target=3D"_blank">ietf.shinji@gmail= .com <mailto:ietf.shinji@gmail.com> <mailto:ietf.shinji@gmail.com <mailto:ietf.shinji@gmail.com>>> writes:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> As you point out= , the other responses(407, 420, ...) cause the same problem.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> But session-time= r is essentially a kind of pre-condition, so I'd like
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> to avoid incomin= g calls to fail because of it. And I'd like to sort
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> out also the rul= es in early dialog.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> On 2020/05/27 19= :16, Christer Holmberg wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> A proxy reje= cting a request is not unique to the session-timer.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> If Alice rec= eives a 422 she can send a CANCEL (if other early dialogs
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> have been es= tablished), and then a new initial INVITE.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > (This has a larger s= cope than just session-timers.)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I don't know if = the above writers intended this point, but reading what
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > they have said sugge= sts to me this possible behavior for proxies (which
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I don't recall s= eeing suggested):
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Note that 422 is one= of a number of "pre-condition failure" response
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > codes.=C2=A0 Those h= ave the properties (1) when they are generated, they are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > generated nearly imm= ediately from the INVITE, and (2) the UAC can adjust
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the INVITE to preven= t them.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Suppose that if a pr= oxy receives one of these "pre-condition failure"
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > responses, it immedi= ately (or with short delay on a human scale) cancels
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > all remaining forks = of the transaction and returns the failure response
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > upstream.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > The effect is to spl= it the "early dialog" phase into two sub-phases, (1)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a very short phase w= here the forking of the INVITE effectively probes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for proxies and UASs= that object to the the INVITE for "pre-condition"
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > reasons, and (2) a l= onger phase which resembles the current early dialog
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > phase.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > There are probably r= efinements needed to make this work in all cases.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Dale
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0__________________________= _____________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0 > sipcore@ietf.org <mailto:sipcore@ietf.org> <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>=
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mail= man/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >
>
--000000000000d810e905a7158e74-- From nobody Tue Jun 2 05:01:18 2020 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 97B503A03EA for ; Tue, 2 Jun 2020 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 c2WHnPDy1mcE for ; Tue, 2 Jun 2020 05:01:16 -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 688B63A0366 for ; Tue, 2 Jun 2020 05:01:16 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 052C1CIx075412 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 2 Jun 2020 07:01:13 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591099274; bh=ehAxAThglgK1obiKmVASthZPXUFR5xcltAqt1X1yHt8=; h=To:From:Subject:Date; b=DUhEHDCxFMAT+iTUQeRXNyasxndsxbl7EhmoX7t/NKZA58TPXc9w/te+DU4i2wJaX YIausvvmavxpLhyVoW+/uj6+rYCNJmXbSWxXO7boFCUkxEi/7enDZivkpVaReXt+6Y 3Xj6z+TMr5JIDYYOKNFgEign1Vq4uLd1JE2IzrjY= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: SIPCORE From: "A. Jean Mahoney" Message-ID: <67f63256-0b1e-e7ed-d2b9-86686be2f7fa@nostrum.com> Date: Tue, 2 Jun 2020 07:01:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] IETF 108 - sipcore meeting? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 12:01:18 -0000 Hi all, Anyone have anything they want to discuss online during IETF 108? Please let the chairs know by June 10th. Thanks! Jean From nobody Thu Jun 4 18:53:55 2020 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 0A6A53A1131 for ; Thu, 4 Jun 2020 18:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fmbHZn2bPXh for ; Thu, 4 Jun 2020 18:53:52 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 C4C703A112F for ; Thu, 4 Jun 2020 18:53:52 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id r10so4373573pgv.8 for ; Thu, 04 Jun 2020 18:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=acYqW9sl3UKfthP4Sx3EpAIGmT1HMPfgtRdYz6rQwvU=; b=J0kFqeplAnB+ML5CRbxLSdnj9nhvlgEMNC1zwXywCORlKgcl8sYDKrWukzrl4MbIaM OKwVeHgHO/Ysj7+o9MH5KM8TBvp3+g+GD6GzZ0P4WyGyoOTC9TRE3PLlmcHSX7YD8k1b ydTYqE8jTt87vbnU7EuRS4IfRqkyC2v5ADpphwMRU1y+x8t3RkUSNYnBUeVd/MrmMhH+ xbfHtJigSXSz2UgJk2uIiAha/4hv+jsfhlkrxohUiYSZrRLEkV+2f9CaJN4JPRMw2/tl R7lBroVWYymdyj2UsasJjZgmnqplG/qAGq8NN9ojVn0QdZ4mj6+5yXJFzSylQbl8chOj 3enA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=acYqW9sl3UKfthP4Sx3EpAIGmT1HMPfgtRdYz6rQwvU=; b=fs6WkHtk74kNNgWabR1sT2893IwOB6n0UrmKcIl/CgJVgd8Y/WZBobe3BSZ6SnRJBi b02v7F6ZjCOEwAh/KomQdD+yoqCxTe92wMVPFamdFeozAxIZg1gVzzEvZyWQsRXkWUN+ k8UXnrRHcBc7oHr1cyj8kbTyJ7VZ/LkFcI1e5IJlRsHO3jsmhAE2g88XVNSHTxfHEPV1 b3cjnJFK6yMcp4fMBUoK1t4ig47WyKA1m8U7dvPBLN7jhwjNpgvcjA7IausYJ+VLE1wx +Tqwo04hn8cAbCybsEuY9MJRimMUQ01C5Kd9rANquGDlNjgaWzU44iLnNfEzRw8cAfXF 9wkg== X-Gm-Message-State: AOAM530aPRQAQt77pVnTY6MovWVHLuFNvyM1OT2fcmJ3Mxc4QTlE39QQ 3WuYxU5bTL1dvfwHiulB1PM= X-Google-Smtp-Source: ABdhPJy7yz6hKdB8ILKvwGroJXTP6NjLrpOGO8M7KrzywmVofCd/pbyodOwFGpnghgL5RiTJ9wucRA== X-Received: by 2002:aa7:9ac5:: with SMTP id x5mr7156235pfp.234.1591322032087; Thu, 04 Jun 2020 18:53:52 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id g19sm5715042pfo.209.2020.06.04.18.53.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 18:53:51 -0700 (PDT) To: "sipcore@ietf.org" References: Cc: Christer Holmberg From: OKUMURA Shinji Message-ID: <64cdc12c-e615-f214-75fc-2e822361c8a0@gmail.com> Date: Fri, 5 Jun 2020 10:53:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 01:53:54 -0000 Hi, Is the scope of 4028bis below? ・solving the session-timer glare situation ・Errata ・another bug fix Regards, Shinji On 2020/05/11 20:36, Christer Holmberg wrote: > Hi, > > Now, when the sip-oauth draft is more or less done (in the RFC editor’s queue), I intend to take up the work on 4028bis (session-timer) again. > > We previously had e-mail discussions and phone calls, there is an issue tracker on GitHub, and we discussed the suggested solutions at IETF#103. To refresh your memory, please take a look at the video: https://www.youtube.com/watch?v=C2yeckBmgPg (the session-timer presentation begins at around 7:30 minutes). > > The decision to make a bis (instead of an update draft) has already been made, but please take a look at the technical suggestions for fixing the glare situation. > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jun 4 19:13:53 2020 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 E01EE3A113E for ; Thu, 4 Jun 2020 19:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GZF6ZfcdIOYC for ; Thu, 4 Jun 2020 19:13:50 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 9AC4D3A114A for ; Thu, 4 Jun 2020 19:13:50 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id p21so4375096pgm.13 for ; Thu, 04 Jun 2020 19:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2rjwiMN5MI66ZW4oqgl4S3dOG1FlCY9hU7YC6d1zvO4=; b=ONNbZRkfvQxnf8g7QxjgtLblBePgKAgZA7P1VCl0Ghse2BKcm9PTcSmAwDEiENDnyK s+1HmWJd0RlHgdVEg49jtsFLyVSvXjB8HCDQA/bdf2rP8TKp/Yv0M0Sulxj5VKcGVCZP UeL+KzcIHCzG1cdw69gNa1x/wqny6fvbb/nxAq20LFcUHZjrABxFs6Nb6lJjzy+cZ0L9 6goEted9MfxnMI0BEsOpD0DsMQyM7hvdSpuaEb89E7yi2HNGksPes7qaPzxXH+bsnshq gr2YjG3M0RAN5VzpNz4U9qXN8l2R0CmeIX1RYUkhmK0XqRrjFGrKWUdZ7mvjXFQAJGkM tlgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2rjwiMN5MI66ZW4oqgl4S3dOG1FlCY9hU7YC6d1zvO4=; b=WRzu4daXWp4Nhq2JY9namaiBO1hUS6hFFmdT1+M/W0a7pfhU6BNGFVJ4HJYARlRqMw f77TNGTZTgdr425hoQCOdy01BnBgh3ryMmmFeaJ8vW752Yeqxs8Bgbt1/4Q41BbCdXp0 l+bXm6tgQ3TKKTEuoGNGONM/MnPMRYbxG3JYWThPc4kxh5KLaem8L2UepvfIkm7Phfba Wv+ONi11mVjyFOB8D/kd8Dz8TNoM1Z4XMtAB+B5sy8W3KNzgAIN5AIzJ4Qt9Y7UUzvPo 9Ljx0OXGjoh34YanZrfuSvaqumSB0LkxBgdkERQmBkNuIiGUZJgseSdbzGc9pPG5iQSL r6HQ== X-Gm-Message-State: AOAM532zUWOzEOBdVttbykSJDQ2DrzmCD6Eo+3pVkQRaVyL1n8H/Ew3y 88ZgFZS1n+eP8CNMCeVdsDLfEoAX X-Google-Smtp-Source: ABdhPJwImAjJRzyS6aQeaCWrM3vZUzwsQXtwTV/WaWE4IqTvEfv2kqXygkN5zAc8hJ9dfLJf/Hna7A== X-Received: by 2002:a63:3e0e:: with SMTP id l14mr7152376pga.187.1591323228746; Thu, 04 Jun 2020 19:13:48 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id l23sm4973787pgc.55.2020.06.04.19.13.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 19:13:48 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Cc: Christer Holmberg References: <64cdc12c-e615-f214-75fc-2e822361c8a0@gmail.com> Message-ID: <86453855-aad2-a51f-0f5a-1d402b9359ad@gmail.com> Date: Fri, 5 Jun 2020 11:13:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <64cdc12c-e615-f214-75fc-2e822361c8a0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 02:13:52 -0000 and d) clarify unclear descriptions. On 2020/06/05 10:53, OKUMURA Shinji wrote: > Hi, > > Is the scope of 4028bis below? > a) solving the session-timer glare situation > b) Errata > c) another bug fix > > Regards, > Shinji > > On 2020/05/11 20:36, Christer Holmberg wrote: >> Hi, >> >> Now, when the sip-oauth draft is more or less done (in the RFC editor’s queue), I intend to take up the work on 4028bis (session-timer) again. >> >> We previously had e-mail discussions and phone calls, there is an issue tracker on GitHub, and we discussed the suggested solutions at IETF#103. To refresh your memory, please take a look at the video: https://www.youtube.com/watch?v=C2yeckBmgPg (the session-timer presentation begins at around 7:30 minutes). >> >> The decision to make a bis (instead of an update draft) has already been made, but please take a look at the technical suggestions for fixing the glare situation. >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From nobody Thu Jun 4 20:27:44 2020 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 9809E3A11B6 for ; Thu, 4 Jun 2020 20:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 H4uNY-Y-N90o for ; Thu, 4 Jun 2020 20:27:41 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070.outbound.protection.outlook.com [40.107.20.70]) (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 B2BCF3A11B2 for ; Thu, 4 Jun 2020 20:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OJbYQ0mnL6KSftsQdZeQeUBgx0vJdTg+xLP/5h1S+AZLIQoGjhREuzNRQ+6JMo2SpbnpiImcBvCzOaDYsFkMJ3r0E0LUhKzFDKFeCBMuFOR6+MTnnyn3+KwHgjnCRLxKXhHWCVNVYynzzE+TWAcRfAeUp5GhNIgfAMMI9PF6cpp04Q6YIs71z8I08baQZgigxDuoTEoi3YF9IrJIQBvIKg5535efpQpBAdnFYg8ntYMKZJlVT4bcossUlikBrWbMayk2dsmXnubH/NcvYCyBqrVgW6EDQsQl75YzYdQMVSXeRHjJ6NHpTIOmK7XA5OnD4BrnclaZhlvSP6057G6iRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jwjyMu6Dr2Z2jCJlqR+SqB25ewrxCU9qVa6/04WKE3E=; b=XJQVdCBxmgQtAd4s1p4IvdwynGHE6D1t5kZ2gW99CQN1bFTPVepo8b6tVCdiXqXl1pjgYYNMuJJfJ7uEiBT/Atr6LrNSt6W3uu8Z0uGNcvhVTN+YV4EeLeiwY5bi4eyXhFjBUAHdtJftAEMDy8h65XwdINKp80VldQKAYJkEMP1o9qcViUoPFwrurWJT2aQnePOXu+MIGKWtHukHylo3M8rmEiedpbopmAJTj2jN/8MYq1KIV7h+0OutW3jIQtY1g+QtggJz8vg1FC//eYnfyIvllsk4deXeEPHjHf8ixjzvNmdSoebNVTpI/MV2MKCTtKftw6p5CP/8jhPvV6C+hA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jwjyMu6Dr2Z2jCJlqR+SqB25ewrxCU9qVa6/04WKE3E=; b=eO1Fr8SRL3SECR3U5diAqRnJxb7fA/R+G2M4uigeXlR73PMIaHkR+hOca0BSzcgGY3HWILMZAWrYC9ty/JnZRbchuP2pNV4je29l+TBDaJZtfeJFzHkWGio+ZHwjJtm1MydXvKGRp+Vjq0Vjn4FyldRet+2CEeiJSf1KXvJ0Vr0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9; Fri, 5 Jun 2020 03:27:38 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3088.010; Fri, 5 Jun 2020 03:27:38 +0000 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" CC: Christer Holmberg Thread-Topic: [sipcore] 4028bis: memory refresh Thread-Index: AQHWJ4hoBAIXqjuyIkyXKiS7M/GbTqjJaT6AgAAFkoCAABMIcA== Date: Fri, 5 Jun 2020 03:27:38 +0000 Message-ID: References: <64cdc12c-e615-f214-75fc-2e822361c8a0@gmail.com> <86453855-aad2-a51f-0f5a-1d402b9359ad@gmail.com> In-Reply-To: <86453855-aad2-a51f-0f5a-1d402b9359ad@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eee18724-dfa4-4b94-9cea-08d8090065ad x-ms-traffictypediagnostic: AM7PR07MB7012: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LBxmKLlof+mzeIApnbzPNKVwZIHINwl3cIhvPI+cm6I+B7ZGEBUWPud3tkIFspQsaEW95gara/rNTLCzNI0xOfXKLd/sRWH9/QrLWpl1njSyxIHWp/dnP1v4fl12d57RS+T62ad72riQvoLeqFR9qoFfdw3e15K5UCGeaX9ivWI2AbRJFkaDBDYK0ysU/NyJ8Pd7r/dGJRiZczkqNcCVkygYme9OSAAExbu46gJ2+vSzQFVO+4MnwjKACngr6K25GIo3jvdBpLklxNcIn/nvGTXwRssdA9GEKyTJvOzO0xuz73U+TNJR4TkWieF9nBsBaOLAzwix1I9blP+fo/voWPUNwtg5ocw6gGn9O5/jtFd6/nqaoeYu1Mi+xG36WPkxeAh0/WYdmOo0yv3u6lxY5g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(366004)(376002)(136003)(55016002)(966005)(44832011)(9686003)(83380400001)(186003)(8936002)(33656002)(52536014)(478600001)(5660300002)(8676002)(4326008)(66574014)(86362001)(316002)(6506007)(71200400001)(66556008)(7696005)(2906002)(53546011)(76116006)(66476007)(110136005)(64756008)(26005)(66946007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DNup5117yNT5NotaL71OEb5JXiuGXC2NogOXuERsLmdzGHkg0tYPuADBc9UUoiHgArm4hzdkw9rZCXvSkokmTIKckkE3EOqaedBAiqrSGh+o2NGujUpvh9DXMzfsgSASnIUaQ4a+d1KBoWrPfbfXkqXRwRQON1FJlYZcw3/CD3N+v4JJTut1jg1g25WGd5dgkMAse9cMVEDpQ1itTGD3GHF4UXj/4fdWL5e87z5CVfkWuNJQLIX766Es1rFYm3YloPRug38H/sM6kfW0QE3UH1Yvie31azdBmBcw6Kvx4bQ9W0XOdZhPHw0fWM7yyuziYHkU183vyThY0L3/mTcL8j79kuhLLWIAmBejaJJltTIPT5DRVWKWJ08zNwIIJC5FVZAqsOBk5kKORuRtDCphMOChOu7ZiZLmDFmfQa4Sk+dM+I291UJKwaewrrvtgmuCT4xAeLvHKgbiSLhgERgFg/ipXkZMqK2SNYmR0aM1NJQ9aRAdAMlN9ffkKBlGp6Ik x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: eee18724-dfa4-4b94-9cea-08d8090065ad X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 03:27:38.2416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4jf+0fXcMXBriMzvqh++ZbVBqQfKh3SOun9NNxvyrSL2XegKA2zBlHvrA/BViquOmmMvojWhf5fDzz86cKhgM9u71ZvRw2bGGjVelXyzcSc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB7012 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 03:27:43 -0000 SGksDQoNClRoZSBzZXNzaW9uLXRpbWVyIGdsYXJlIGlzIHRoZSBtYWluIHNjb3BlIG9mIHRoZSB3 b3JrLg0KDQpCdXQsIG9mIGNvdXJzZSwgaWYgcGVvcGxlIGlkZW50aXR5IG90aGVyIGJ1Z3MsIHdl IG5lZWQgdG8gaGF2ZSBhIGxvb2sgYXQgdGhvc2UgdG9vLg0KDQpCdXQsIGFzIHdhcyBwcmV2aW91 c2x5IGRpc2N1c3NlZCwganVzdCBiZWNhdXNlIHNvbWV0aGluZyBjb3VsZCBoYXZlIGJlZW4gZG9u ZSBpbiBhIGRpZmZlcmVudCAoYW5kIHBlcmhhcHMgYmV0dGVyKSB3YXkgZG9lcyBub3QganVzdGlm eSBhcyBhIGJ1ZywgaWYgaXQgb3RoZXJ3aXNlIHdvcmtzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgT0tVTVVSQSBTaGluamkNClNlbnQ6IHBlcmph bnRhaSA1LiBrZXPDpGt1dXRhIDIwMjAgNS4xNA0KVG86IHNpcGNvcmVAaWV0Zi5vcmcNCkNjOiBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmc9NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIDQwMjhiaXM6IG1lbW9yeSByZWZyZXNo DQoNCmFuZA0KZCkgY2xhcmlmeSB1bmNsZWFyIGRlc2NyaXB0aW9ucy4NCg0KT24gMjAyMC8wNi8w NSAxMDo1MywgT0tVTVVSQSBTaGluamkgd3JvdGU6DQo+IEhpLA0KPiANCj4gSXMgdGhlIHNjb3Bl IG9mIDQwMjhiaXMgYmVsb3c/DQo+IGEpIHNvbHZpbmcgdGhlIHNlc3Npb24tdGltZXIgZ2xhcmUg c2l0dWF0aW9uDQo+IGIpIEVycmF0YQ0KPiBjKSBhbm90aGVyIGJ1ZyBmaXgNCj4gDQo+IFJlZ2Fy ZHMsDQo+IFNoaW5qaQ0KPiANCj4gT24gMjAyMC8wNS8xMSAyMDozNiwgQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBOb3csIHdoZW4gdGhlIHNpcC1vYXV0aCBkcmFmdCBp cyBtb3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlKSwgSSBpbnRl bmQgdG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChzZXNzaW9uLXRpbWVyKSBhZ2Fpbi4N Cj4+DQo+PiBXZSBwcmV2aW91c2x5IGhhZCBlLW1haWwgZGlzY3Vzc2lvbnMgYW5kIHBob25lIGNh bGxzLCB0aGVyZSBpcyBhbiBpc3N1ZSB0cmFja2VyIG9uIEdpdEh1YiwgYW5kIHdlIGRpc2N1c3Nl ZCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9ucyBhdCBJRVRGIzEwMy4gVG8gcmVmcmVzaCB5b3VyIG1l bW9yeSwgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSB2aWRlbzogaHR0cHM6Ly93d3cueW91dHVi ZS5jb20vd2F0Y2g/dj1DMnllY2tCbWdQZyAodGhlIHNlc3Npb24tdGltZXIgcHJlc2VudGF0aW9u IGJlZ2lucyBhdCBhcm91bmQgNzozMCBtaW51dGVzKS4NCj4+DQo+PiBUaGUgZGVjaXNpb24gdG8g bWFrZSBhIGJpcyAoaW5zdGVhZCBvZiBhbiB1cGRhdGUgZHJhZnQpIGhhcyBhbHJlYWR5IGJlZW4g bWFkZSwgYnV0IHBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgdGVjaG5pY2FsIHN1Z2dlc3Rpb25z IGZvciBmaXhpbmcgdGhlIGdsYXJlIHNpdHVhdGlvbi4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+ IENocmlzdGVyDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29y ZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Fri Jun 5 00:34:34 2020 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 867E53A1371 for ; Fri, 5 Jun 2020 00:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leh3JUmSVcXj for ; Fri, 5 Jun 2020 00:34:31 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 687953A136F for ; Fri, 5 Jun 2020 00:34:31 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id nm22so2239417pjb.4 for ; Fri, 05 Jun 2020 00:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=SE2M6uKPZxpDVVIe0R0mZFdJUuDweupXGcD0XsSj8I0=; b=K5w1zrEy9wb5jnx1KWlBfnnU8Ypo68paVgZ4BHc6QfmxcJqL1MGaK2PC5G4sjxeBEY xj7vfKorXt1xHZHC/wRuFoBOnnHjesJ5T9Uc2JlaoN1rvF3XdT7PW8XAuBDwbhczDrJW mP40rlrXelcHdmG38D/9KD8Lo3JKmZxkjRD6fYDftiBvUnw2ddqgKnoijLM3T4XDWzek GjBV/DJrHHCVZaR2EuDFIso9zAX+AJWhb+LR2tyMcDkUz4mMB9mfbtWshvIgreZsZ78O RJT6KQLZG7S7prv5qOS0wj3gSG/nYi5fMKmKzqFmOjgvClKVlyH7ZjzUnJnZlHA4p9Je btUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=SE2M6uKPZxpDVVIe0R0mZFdJUuDweupXGcD0XsSj8I0=; b=PLQBhtmTUMsTEkCKIuS/3K2kn0WaDh7G5Sc20eMvyq0FYXh/phekeUcuTA7LOCATdH qV57iE+UnXV+eyF20DCZALXWt9MQK3KbKoSVb9QdZxCbTycpyoeky7pzHv4KX0oe+Td5 7+28gCZMOWBfiDvP9Y3vaWHNs3OmjQLcgqIh8sWGS2FsqeXWqVZ7NV07nt0FS/KFGLHn FQHiqSbjUvg4ng56Dc1bYjwnOwGIOIl/JlQJzHF4rjfD5foWhPBY4k0wkI7Ctc2TVtMv IB1S+95D1L59hqYhxdzfVmpKBtSxxrQI9JhL2V5x9dqmbGFZWp2AigJZ16QmyVPf5Ni4 lqrg== X-Gm-Message-State: AOAM531Y1bl5NfWhP/o/TiI9IeH2qQXpOegU46mWQ8A1i71lL1UV19Kz hNC+V/XXZ4y9IIKR5+PMdN4= X-Google-Smtp-Source: ABdhPJyhqEeaXfSQe31rIVU8fgZpEgKPqTIOH7fVYRRjrIfcvN65APzZtRX3CoQCgUu8svhrYAdxZA== X-Received: by 2002:a17:90a:c250:: with SMTP id d16mr304731pjx.60.1591342470684; Fri, 05 Jun 2020 00:34:30 -0700 (PDT) Received: from [192.168.1.127] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id c194sm6436876pfc.212.2020.06.05.00.34.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jun 2020 00:34:30 -0700 (PDT) To: "sipcore@ietf.org" From: OKUMURA Shinji Message-ID: Date: Fri, 5 Jun 2020 16:34:27 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 07:34:33 -0000 Hi, 11. Security Considerations Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response and force the UAC to continue to generate rapid requests. If the rogue UAS returns again a 2xx with a very small session interval, the attack will continue. To prevent this case, I think the UAC and proxies SHOULD make sure that the SE-value and MSE-value in the response are greater than or equal to the MSE-value in a sent request. And ... what should the UAC and proxies do? Should they modify the response? Is this included in the scope of the bis? Regards, Shinji From nobody Fri Jun 5 00:45:58 2020 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 895233A138A for ; Fri, 5 Jun 2020 00:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 YAiGq52HEHVG for ; Fri, 5 Jun 2020 00:45:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130072.outbound.protection.outlook.com [40.107.13.72]) (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 E02083A1389 for ; Fri, 5 Jun 2020 00:45:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdZf1fS8L5qhnsLRyyaGcQ0USTeHzH0ZtODu+SQHOLRxSC/dPl39Tag3s/ydlJC2ZqSmRsm98W0ks8zjnrXHrE/yNLYhp74YMFS16L4d6iy5YOtzmbu+vSKXp9vM501UD6mIW+U9lbpLT5lkhUbssGDaiYLbhONoIpa4CuotZmrIwMWUAFRbGkeE6YcUc/lWp3ukl3lL3siD7pHh8l+CwVClNH8+tf4o8VvCbk2ag18LrxuJz/qTZ8Cpdsy99v/1NAJSdC4VUIPKUYMBkqvPU6a8XocU4WsBnEjvzkoi+gA9Ak6XYtJc1pybBnxsr2PrO2crQxC72Z7Kb0LAQSl58w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XJmzmiQuumGpNZ7FPoiEBMkqRaqf+9RAoGmO1p8Peks=; b=aFEz74fV4LSwlLFgAc+uVJ9wUZT4jJiT1aCjS9t2SQeSLTs1jrOw/teIc5QOWJ2O5nEqGbpkUY5zYfG2/sp2PJha2vAvhTToGIFfskMxl8IZ0cmupprlGCdTuS3u1SxkjHPH8pUNM9RRrTDyYGYT46btNZZ81sE5lY5RQ9LmN8wWsYUDdV2bMvhY65j816VpaagJctaqp/f4/ixwE/M6dmeZ/TvXE3TntstKmL894RQp6lBryly3gc1gzP+E6inrI4nS5LTIK7M7vNmJQY+borB1qZDTH6ELoElZ3LK0rd11Thhas76lUPCkqKX2XS8KibPL5+jFalKzSm8Sw07Kww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XJmzmiQuumGpNZ7FPoiEBMkqRaqf+9RAoGmO1p8Peks=; b=DCDUiBs7FJOZcHb+JBK/QWGzmtZVadoGqx+S8cHO0er14zu+u/2Z2Xoy+IRhKmsJhwQh7NKx0aIvRl+e9RnDwuCLb9EoylypXFh8k8axUKZe6ZeTnxUOO0cTkTjrAM+MQ1s/O/BQLJfHLE2gspsJG5y2KBG2kc5gYvJZei1iTok= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6771.eurprd07.prod.outlook.com (2603:10a6:20b:1bd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.11; Fri, 5 Jun 2020 07:45:53 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3088.010; Fri, 5 Jun 2020 07:45:53 +0000 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: RFC4028 : bug in 11 Security Considerations Thread-Index: AQHWOwvDeA7xnyMLmkmJp/CM1XW3pqjJpDPQ Date: Fri, 5 Jun 2020 07:45:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 181235ef-b907-4840-ddd4-08d8092479a6 x-ms-traffictypediagnostic: AM7PR07MB6771: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fJUruEYqKBadT57MMRqb+1kXW1ZjIGcYj83oUyzoIu5p/FNrxJV13qlJaojPSR+A8BJOJPX1LzrWEiZSqOT7ZSUOC5cyRliryCZZlFH/bbxyhiSSNQlbdCzWJh2QL2Vc4EXtvXs6uvC/sr9jalicTiGPFziqYLih3DKAs2p+CSnQUxkQmrtT1XD5omdBuQoNyDpvRsLTtvvXS63rVtQQi7zzR++W1Fe2aZDH91EgJzbCAKaBgM94fP/k2O8j8dw5CNby3Za/QTw6ju+WmcEsNdOGpO6ICJCSw3pfzUYIdSq5dPTcCSrfRtD3tZk61Psi592RzvueaeUcsg0J1RliDw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(376002)(136003)(346002)(7696005)(5660300002)(44832011)(55016002)(66574014)(9686003)(86362001)(6506007)(26005)(15650500001)(83380400001)(186003)(66946007)(76116006)(64756008)(66446008)(66476007)(316002)(66556008)(71200400001)(2906002)(110136005)(8676002)(8936002)(33656002)(52536014)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KUG9zTjp6mJNMLrvW+0oEIYr2lQIXW0in0q/IZRRblcp6oZjAT+HkgLgNYnWpnk8fxvXgDz6gx953Eszbz7E3ZpZNASj3En6hRVsq0h21tVdxZur4bDgF1fh/DskCb9R0A+Jhu2un9mzsC30FB4XSH96yyx6+2+bC62n514ys1GEUOoMwVKnpgXbqC8b0S1rjXhf0K9M1yccgeRV7khpzq7wPuD/6ZgZBKhCF0zW4kMstlgL7ean9fbA6xhr7PDssgF/OQWEdebhHGMymAgHaBQfx5KD5vgw4b7LLGqtJQ0Y6HUhimmCPYx1sSWZK1we37tsATjKLthT1t/nJU9GJ7QrxxiOsmTNYnbZ5Vb/93NmvJnbRrbRnWGHwL6pz64J3St4t0w2/14yS2WuXN2sFlksE+Or+jMh+lyzDkBSnHcJaWXP/3o3TD2StwAfq8s836c4r90wRrgPDo8tdkIAUyrFi0M1lYZ1bW3sZdJfRxgmuCxaT85neUiuJxu9IzJ2 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 181235ef-b907-4840-ddd4-08d8092479a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 07:45:53.6928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O+ctV0rOgrLeC1hqEOBRnwdDu+YLJU2PNfGwnCIA1AwWjlZa9znw21/rFcjCPeQOXYzEdKSXCP7/LUcEFC5wLPRXge4NRbzno28zNpYXwmg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6771 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 07:45:58 -0000 SGksDQoNCklmIHdoYXQgeW91IGRlc2NyaWJlIGlzIGEgdGVjaG5pY2FsIGJ1ZyB0aGF0IGNhdXNl cyBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLCB0aGVuIGl0IGlzIHdpdGhpbiB0aGUgc2NvcGUu DQoNCkhvd2V2ZXIsIGlmIHRoZXJlIGlzIGEgcm9ndWUgVUFTLCB0aGUgVUFDIGNhbiBzaW1wbHkg dGVybWluYXRlIHRoZSBzZXNzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9LVU1VUkEgU2hpbmppIDxpZXRmLnNoaW5q aUBnbWFpbC5jb20+IA0KU2VudDogcGVyamFudGFpIDUuIGtlc8Oka3V1dGEgMjAyMCAxMC4zNA0K VG86IHNpcGNvcmVAaWV0Zi5vcmcNCkNjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPg0KU3ViamVjdDogUkZDNDAyOCA6IGJ1ZyBpbiAxMSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQpIaSwNCg0KMTEuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K ICAgIE5leHQsIGNvbnNpZGVyIHRoZSBjYXNlIG9mIGEgcm9ndWUgVUFTIHRoYXQgd2lzaGVzIHRv IGZvcmNlIGEgVUFDIHRvDQogICAgZ2VuZXJhdGUgcmVmcmVzaGVzIGF0IGEgcmFwaWQgcmF0ZS4g IEluIHRoYXQgY2FzZSwgdGhlIFVBQyBoYXMgdG8NCiAgICBzdXBwb3J0IHNlc3Npb24gdGltZXIu ICBUaGUgaW5pdGlhbCBJTlZJVEUgYXJyaXZlcyBhdCB0aGUgcm9ndWUgVUFTLA0KICAgIHdoaWNo IHJldHVybnMgYSAyeHggd2l0aCBhIHZlcnkgc21hbGwgc2Vzc2lvbiBpbnRlcnZhbC4gIFRoZSBV QUMgdXNlcw0KICAgIHRoaXMgdGltZXIgYW5kIHF1aWNrbHkgc2VuZHMgYSByZWZyZXNoLiAgU2Vj dGlvbiA3LjQgcmVxdWlyZXMgdGhhdA0KICAgIHRoZSBVQUMgY29weSB0aGUgY3VycmVudCBzZXNz aW9uIGludGVydmFsIGludG8gdGhlIFNlc3Npb24tRXhwaXJlcw0KICAgIGhlYWRlciBmaWVsZCBp biB0aGUgcmVxdWVzdC4gIFRoaXMgZW5hYmxlcyB0aGUgcHJveGllcyB0byBzZWUgdGhlDQogICAg Y3VycmVudCB2YWx1ZS4gIFRoZSBwcm94aWVzIHdpbGwgcmVqZWN0IHRoaXMgcmVxdWVzdCBhbmQg cHJvdmlkZSBhDQogICAgTWluLVNFIHdpdGggYSBoaWdoZXIgbWluaW11bSwgd2hpY2ggdGhlIFVB QyB3aWxsIHRoZW4gdXNlLiAgTm90ZSwNCiAgICB0aGF0IGlmIHRoZSBwcm94aWVzIGRpZCBub3Qg cmVqZWN0IHRoZSByZXF1ZXN0LCBidXQgcmF0aGVyIHByb3hpZWQNCiAgICB0aGUgcmVxdWVzdCB3 aXRoIGEgTWluLVNFIGhlYWRlciBmaWVsZCwgYW4gYXR0YWNrIHdvdWxkIHN0aWxsIGJlDQogICAg cG9zc2libGUuICBUaGUgVUFTIGNvdWxkIGRpc2NhcmQgdGhpcyBoZWFkZXIgZmllbGQgaW4gYSAy eHggcmVzcG9uc2UNCiAgICBhbmQgZm9yY2UgdGhlIFVBQyB0byBjb250aW51ZSB0byBnZW5lcmF0 ZSByYXBpZCByZXF1ZXN0cy4NCg0KSWYgdGhlIHJvZ3VlIFVBUyByZXR1cm5zIGFnYWluIGEgMnh4 IHdpdGggYSB2ZXJ5IHNtYWxsIHNlc3Npb24gaW50ZXJ2YWwsIHRoZSBhdHRhY2sgd2lsbCBjb250 aW51ZS4gVG8gcHJldmVudCB0aGlzIGNhc2UsIEkgdGhpbmsgdGhlIFVBQyBhbmQgcHJveGllcyBT SE9VTEQgbWFrZSBzdXJlIHRoYXQgdGhlIFNFLXZhbHVlIGFuZCBNU0UtdmFsdWUgaW4gdGhlIHJl c3BvbnNlIGFyZSBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8gdGhlIE1TRS12YWx1ZSBpbiBhIHNl bnQgcmVxdWVzdC4gQW5kIC4uLiB3aGF0IHNob3VsZCB0aGUgVUFDIGFuZCBwcm94aWVzIGRvPyBT aG91bGQgdGhleSBtb2RpZnkgdGhlIHJlc3BvbnNlPw0KDQpJcyB0aGlzIGluY2x1ZGVkIGluIHRo ZSBzY29wZSBvZiB0aGUgYmlzPw0KDQpSZWdhcmRzLA0KU2hpbmppDQo= From nobody Fri Jun 5 02:35:39 2020 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 2EEBB3A1417 for ; Fri, 5 Jun 2020 02:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XoJh0Hzwz7jk for ; Fri, 5 Jun 2020 02:35:36 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 40BB03A1411 for ; Fri, 5 Jun 2020 02:35:36 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id k15so7112750otp.8 for ; Fri, 05 Jun 2020 02:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B4/poMTghnB5BwNWmskgRIbj8AVu00mdFoAZrYAqvq4=; b=Qok+rpvBWfnk3gVe1Mz77wGDMZE/6qxZzDVkPENa+Lq90Q/5uOCqRRa3k+g+wCaUN6 MVoLEcp85XtFqKRsq2xxLBxyGJYudBuLghtbzGJSTp8oalRLAo8LE9CgKr6HilJWY7k2 IixmhnMJinJ86wLXU96rKoWgUlVwtwCsoW8OuVadYw1YAYNZ32HMZq4jWbWbTVO+tR25 lHNNqHQLg+CtSXUABkSEINCcySKLXIiCV1O5wT9EY9ATZNdQ+aGQd5LgUENUor9+uXhL AStjTdIhWLHIRR/wFn3l16oNQ3sqZ/EPeQYreYv00nnHhBsvP0qB1V3A8BzIuvAI4uZw 56Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B4/poMTghnB5BwNWmskgRIbj8AVu00mdFoAZrYAqvq4=; b=LANRQj+USzDO272LMZeetZBxZyOWfX0vJ54M2IzH00wurFloCE5NglG3q+kBnqCwo/ p2F0Rcks75b55KjGcvj9+Wy1DFi4F+WyVwwXHikNxT3LonOGsQwaLR6WJxUyy90sTvNr 0fEul047BuXfk7GdS/iQls1aRiybmZBXGjckKimstxkf/x15sWjazvUEh2tt/BWb6tBN 4TdQcA+g4PWl52uYiU/qfDCY0YzmL9B4VKMfPQd37tzoiKRRBeWs8DBSvFbLLdFbZHiD osXKFYgNQUl/keo993v+NAAKn7AgK2yUfKKEk74mt0dJZOBcFeUnBLj61ADAIyQDdb5a Dfzg== X-Gm-Message-State: AOAM532l8KTSmaS3ykKwJtgw1d6eKxP+JjxA26abY+bAZYZ7Pc9LYbDJ LUnW7qQ9ufwoeGMlH4tGo6V6OpzLPeo= X-Google-Smtp-Source: ABdhPJzno8FOMfuPH6etqtSiYyg+AiBIEKwFj0oZ+8gLA7r2rk8/2HNdeuO9RqLGBHTBAOXP4S1+jA== X-Received: by 2002:a05:6830:2306:: with SMTP id u6mr6613516ote.57.1591349734979; Fri, 05 Jun 2020 02:35:34 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com. [209.85.210.47]) by smtp.gmail.com with ESMTPSA id 7sm1776076oti.25.2020.06.05.02.35.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jun 2020 02:35:34 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id b18so7112644oti.1 for ; Fri, 05 Jun 2020 02:35:33 -0700 (PDT) X-Received: by 2002:a9d:604e:: with SMTP id v14mr7041632otj.39.1591349733164; Fri, 05 Jun 2020 02:35:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Fri, 5 Jun 2020 05:35:21 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: OKUMURA Shinji , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008f207005a752fbf7" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 09:35:38 -0000 --0000000000008f207005a752fbf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Proxy, if it receives a 2xx response with Min-SE header set to a value lower then Min-SE set by the proxy in the corresponding request, should increase Min-SE to the desired proxy value. UAC, if it receives a 2xx response with Session-Expires set to a value below Min-SE in the response or original request from the UAC. should immediately terminate a call. Unfortunately, proxy has no graceful way to terminate a call, so if both UAC and UAS are rogue, this will result in frequent session refresh transactions. In practice, this is not an issue, since proxy, when communicating with untrusted end points, typically have a some sort of dynamic rate limiter to prevent denial of service attacks such as opensips PIKE module ( https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to efficiently drop SIP message from badly behaving clients. Best Regards, _____________ Roman Shpount On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg wrote: > Hi, > > If what you describe is a technical bug that causes interoperability > problems, then it is within the scope. > > However, if there is a rogue UAS, the UAC can simply terminate the sessio= n. > > Regards, > > Christer > > > > -----Original Message----- > From: OKUMURA Shinji > Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34 > To: sipcore@ietf.org > Cc: Christer Holmberg > Subject: RFC4028 : bug in 11 Security Considerations > > Hi, > > 11. Security Considerations > Next, consider the case of a rogue UAS that wishes to force a UAC to > generate refreshes at a rapid rate. In that case, the UAC has to > support session timer. The initial INVITE arrives at the rogue UAS, > which returns a 2xx with a very small session interval. The UAC uses > this timer and quickly sends a refresh. Section 7.4 requires that > the UAC copy the current session interval into the Session-Expires > header field in the request. This enables the proxies to see the > current value. The proxies will reject this request and provide a > Min-SE with a higher minimum, which the UAC will then use. Note, > that if the proxies did not reject the request, but rather proxied > the request with a Min-SE header field, an attack would still be > possible. The UAS could discard this header field in a 2xx response > and force the UAC to continue to generate rapid requests. > > If the rogue UAS returns again a 2xx with a very small session interval, > the attack will continue. To prevent this case, I think the UAC and proxi= es > SHOULD make sure that the SE-value and MSE-value in the response are > greater than or equal to the MSE-value in a sent request. And ... what > should the UAC and proxies do? Should they modify the response? > > Is this included in the scope of the bis? > > Regards, > Shinji > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000008f207005a752fbf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Proxy, if it receives a 2xx response with Min-SE head= er set to a value lower then Min-SE set by the proxy in the corresponding r= equest, should increase Min-SE to the desired proxy=C2=A0value.
<= br>
UAC, if it receives a 2xx response with Session-Expires set to a v= alue below Min-SE in the response or original request from the UAC. should = immediately=C2=A0terminate a call.

Unfortunately, proxy = has no graceful way to terminate a call, so if both UAC and UAS are rogue, = this will result in frequent session refresh transactions.

In practice, this is not an issue, since proxy, when communicating= with untrusted end points, typically have a some sort of dynamic=C2=A0rate= limiter to prevent denial of service attacks such as opensips PIKE module = ( https://opens= ips.org/docs/modules/3.1.x/pike.html=C2=A0) , which are used to efficie= ntly drop SIP message from badly behaving clients.

Best Regards,
_____________
Roman Shpount


On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg <chris= ter.holmberg=3D40ericsson.= com@dmarc.ietf.org> wrote:
Hi,

If what you describe is a technical bug that causes interoperability proble= ms, then it is within the scope.

However, if there is a rogue UAS, the UAC can simply terminate the session.=

Regards,

Christer



-----Original Message-----
From: OKUMURA Shinji <ietf.shinji@gmail.com>
Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34
To: sipcore@ietf.org<= /a>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>
Subject: RFC4028 : bug in 11 Security Considerations

Hi,

11.=C2=A0 Security Considerations
=C2=A0 =C2=A0 Next, consider the case of a rogue UAS that wishes to force a= UAC to
=C2=A0 =C2=A0 generate refreshes at a rapid rate.=C2=A0 In that case, the U= AC has to
=C2=A0 =C2=A0 support session timer.=C2=A0 The initial INVITE arrives at th= e rogue UAS,
=C2=A0 =C2=A0 which returns a 2xx with a very small session interval.=C2=A0= The UAC uses
=C2=A0 =C2=A0 this timer and quickly sends a refresh.=C2=A0 Section 7.4 req= uires that
=C2=A0 =C2=A0 the UAC copy the current session interval into the Session-Ex= pires
=C2=A0 =C2=A0 header field in the request.=C2=A0 This enables the proxies t= o see the
=C2=A0 =C2=A0 current value.=C2=A0 The proxies will reject this request and= provide a
=C2=A0 =C2=A0 Min-SE with a higher minimum, which the UAC will then use.=C2= =A0 Note,
=C2=A0 =C2=A0 that if the proxies did not reject the request, but rather pr= oxied
=C2=A0 =C2=A0 the request with a Min-SE header field, an attack would still= be
=C2=A0 =C2=A0 possible.=C2=A0 The UAS could discard this header field in a = 2xx response
=C2=A0 =C2=A0 and force the UAC to continue to generate rapid requests.

If the rogue UAS returns again a 2xx with a very small session interval, th= e attack will continue. To prevent this case, I think the UAC and proxies S= HOULD make sure that the SE-value and MSE-value in the response are greater= than or equal to the MSE-value in a sent request. And ... what should the = UAC and proxies do? Should they modify the response?

Is this included in the scope of the bis?

Regards,
Shinji
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--0000000000008f207005a752fbf7-- From nobody Fri Jun 5 06:26:41 2020 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 6AC933A080B for ; Fri, 5 Jun 2020 06:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 T-wbpDUGQQq4 for ; Fri, 5 Jun 2020 06:26:38 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 E1DBD3A080E for ; Fri, 5 Jun 2020 06:26:38 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id 5so2732360pjd.0 for ; Fri, 05 Jun 2020 06:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=db+yIv6xq7T2123rmrixon4h5vwshjwgEQLPEHtv4G4=; b=kwXrCMfYtjb9Wkinqnyc8w0yeOKuHNayP3/eKyUAdBJ3p+70J3fMkwPUbEW6y1m7R8 UPnCQAZmoQj4bFnnmfyxVzdKog1/kVrd1I4V+JVygVRt+6Y3iWV694gdAmRHOPmq6Wnu 9w+PjoKRtSsDCPiMbC/ijJOcnXUZmm7CKnQywmLkrOaYdin3UffTEkFCRvmLjl8bpCki n3ZC4OKcpGOHQe3+oMz8FAMgxAv3FcKwS8nUrrWhPLaSX556nKBR5o1zmS/PYVwGBym8 QRXdyC1jtuE7Ll0auZedSKZTFpH3sWprKf0yWElS/W7TAITNsmLmZEvznqLSCfQh/aTA dHuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=db+yIv6xq7T2123rmrixon4h5vwshjwgEQLPEHtv4G4=; b=WJ3KrIgv/pbfF3j7Kru/Kjcx66jIx0mgTeNn/XUz2qU5UlI5uX7YfavgezOp1zLBOy pSCw/Gev1Htm+ldA39JvqGGjUa4Vk9ZloEHPT345uW4+EraqubDPQIcfuV1SqXbGBGeG ScXmIvc3yG2BhHFZJGAJ/gYahP2JOtrZ6LdYcuV9zI0IHCLVVgNhXZ/yB077A6X/mhPa GFbahlQa237Qdaa1kAGtv/+l5S6bzu/E3RsndoHuLyI27MqYrfkpMrYN5MFixm/Fxh5L KamCjcJmgBSvuJw2ZL4gnq+mcMQ5nfHSDEQhbG7bch3psdLcGAUP2V9tue/mW416trSA kTWA== X-Gm-Message-State: AOAM531LxlJm6L9MKcs/tJZJASTdxjktvc96DUsJl8Q1H+NFVim3+usV 9+58SCB8IGPOE8qYjR/MUt5VLPzO X-Google-Smtp-Source: ABdhPJyBmbF3CIymPailLOZjpvPiNsyJ17SO9iaAcxOrgkqz5dZNyHmCRD3qXmf+HwZXZq5nTNJh8Q== X-Received: by 2002:a17:902:bf47:: with SMTP id u7mr9666333pls.159.1591363597057; Fri, 05 Jun 2020 06:26:37 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id p30sm6186471pgn.58.2020.06.05.06.26.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 06:26:36 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount , Christer Holmberg References: From: OKUMURA Shinji Message-ID: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> Date: Fri, 5 Jun 2020 22:26:27 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200603-2, 2020/06/03), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 13:26:40 -0000 Hi, A 200 response has no Min-SE header. My suggestion is below. In this case, the UAC and proxies should follow the procedures defined in section 7.2 and 8.2 as if the Session-Expires header field were not in the 2xx response. Regards, Shinji On 2020/06/05 18:35, Roman Shpount wrote: > Proxy, if it receives a 2xx response with Min-SE header set to a value > lower then Min-SE set by the proxy in the corresponding request, should > increase Min-SE to the desired proxy value. > > UAC, if it receives a 2xx response with Session-Expires set to a value > below Min-SE in the response or original request from the UAC. should > immediately terminate a call. > > Unfortunately, proxy has no graceful way to terminate a call, so if both > UAC and UAS are rogue, this will result in frequent session refresh > transactions. > > In practice, this is not an issue, since proxy, when communicating with > untrusted end points, typically have a some sort of dynamic rate limiter to > prevent denial of service attacks such as opensips PIKE module ( > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to > efficiently drop SIP message from badly behaving clients. > > Best Regards, > _____________ > Roman Shpount > > > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg 40ericsson.com@dmarc.ietf.org> wrote: > >> Hi, >> >> If what you describe is a technical bug that causes interoperability >> problems, then it is within the scope. >> >> However, if there is a rogue UAS, the UAC can simply terminate the session. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: OKUMURA Shinji >> Sent: perjantai 5. kesäkuuta 2020 10.34 >> To: sipcore@ietf.org >> Cc: Christer Holmberg >> Subject: RFC4028 : bug in 11 Security Considerations >> >> Hi, >> >> 11. Security Considerations >> Next, consider the case of a rogue UAS that wishes to force a UAC to >> generate refreshes at a rapid rate. In that case, the UAC has to >> support session timer. The initial INVITE arrives at the rogue UAS, >> which returns a 2xx with a very small session interval. The UAC uses >> this timer and quickly sends a refresh. Section 7.4 requires that >> the UAC copy the current session interval into the Session-Expires >> header field in the request. This enables the proxies to see the >> current value. The proxies will reject this request and provide a >> Min-SE with a higher minimum, which the UAC will then use. Note, >> that if the proxies did not reject the request, but rather proxied >> the request with a Min-SE header field, an attack would still be >> possible. The UAS could discard this header field in a 2xx response >> and force the UAC to continue to generate rapid requests. >> >> If the rogue UAS returns again a 2xx with a very small session interval, >> the attack will continue. To prevent this case, I think the UAC and proxies >> SHOULD make sure that the SE-value and MSE-value in the response are >> greater than or equal to the MSE-value in a sent request. And ... what >> should the UAC and proxies do? Should they modify the response? >> >> Is this included in the scope of the bis? >> >> Regards, >> Shinji >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From nobody Fri Jun 5 22:44:21 2020 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 5C6E83A097D for ; Fri, 5 Jun 2020 22:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxj54yeRML0R for ; Fri, 5 Jun 2020 22:44:18 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 3EEFF3A097C for ; Fri, 5 Jun 2020 22:44:18 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id 5so3704825pjd.0 for ; Fri, 05 Jun 2020 22:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=B2wS57BMuqGZ4KaQ2vBc8W8Kbc14p4O/JReoyQOphQs=; b=a3wW1NTN6EtOsPX8ftdbGDPjSi0Rsw2dLVscniAeMGzTttNVokx/0v6sChuTY6vNUp WoK8Xbxb8qK1oPYXV6hCvoBJ1/CazBd/lGRk5P7bP2Wvu6co9PVRVXlTy5W67WpLxryH DIoY+B7+shv5hfjQXWvNQag8+gJEBdzj1JeQx7AOlQedksiBDCxfybHPYYpBKv3OKDV4 UfMM98c1Ij2pY/HcGC+5LeH7fHCNMIsvJRL00eZi/siGSKGzVJvJKi5LQqk+HWqNYqIm pSLTy5Da2az9ofBFuxqtkH3NK7sxtZqEyvDCHTnYL80Q9XYNrkPyi4lH+e0jVELZeS0B 72jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=B2wS57BMuqGZ4KaQ2vBc8W8Kbc14p4O/JReoyQOphQs=; b=GCZAj2DNQf2ViYGBZdzgVqkjbmxb7n75We/KwObgmL9OYFg1oOqlhBbq4SNAmSTQOl PLQBB78NdZp4xy9fotXisPZEqAM4e3MUKnegarUrNCS8800vWayzH/RpY/ClzCTo9Imb RxnrwvC0jxPaifbPKZvmNhgayUSE43DgJiwXu945H+nD7ca1WUWq62e0HqHDifsNLTV2 h6XcL5oF8IDSCcAShuF+O99R49MJwEvFG/OqJVJC/khjIEGuv6scZlxtwsuQ/ZS+rp0x bfVUZX/n+ajVEvjQr7yMxuNvvU4rASk3xnhksGZgLMhZFZO8UyX3pqEkpoFrXMS4kPDz O3zw== X-Gm-Message-State: AOAM531G0jUugrEIiLb8Kb1a/GGFu6TST/7znUTpdiB1Z8tRKyGXxCEr Z8iYPaFBedUEP/xsQEQbBss= X-Google-Smtp-Source: ABdhPJzZw9SrqTiuY+yYQyVa0cZ0YTa4oIEpx6VIB3jMepXlgBDEB+CWULBpd9yGGKbQb/xAlA1Uxw== X-Received: by 2002:a17:90a:69c3:: with SMTP id s61mr6700603pjj.212.1591422256370; Fri, 05 Jun 2020 22:44:16 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id gg10sm9937492pjb.38.2020.06.05.22.44.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 22:44:15 -0700 (PDT) To: SIPCORE From: OKUMURA Shinji Message-ID: Date: Sat, 6 Jun 2020 14:44:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200605-4, 2020/06/06), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 05:44:19 -0000 HI, ======================================================================== 7.4. Generating Subsequent Session Refresh Requests The value of the Min-SE header field present in a session refresh request MUST be the largest value among all Min-SE header field values returned in all 422 responses or received in session refresh requests, on the same dialog, if a dialog has been established. If no dialog has been established, the Min-SE header field value is set to the largest value among all Min-SE header field values returned in all 422 responses for an INVITE request with the same Call-ID. A result of this rule is that the maximum value of the Min-SE is effectively 'cleared' once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used. ======================================================================== My interpretation is as shown in the figure below. Alice Proxy P1 |(1) INVITE | |SE: 1200 | |MSE: 300 | |----------->| <-- initial MSE is 300 |(2) 422 | |MSE: 900 | |<-----------| <-- MSE is set to 900 |(3) ACK | |----------->| |(4) INVITE | |SE:1200 | |MSE:900 | |----------->| |(5) 200 OK | |SE:900 | |<-----------| <-- dialog is established and MSE is cleared |(6) ACK | |----------->| |(7) UPDATE | |SE:900 | |MSE:300 | |----------->| <-- MSE is 300 In order to understand this description clearly, I think it is necessary to show concrete examples. And when an early dialog is established, another examples is necessary. Regards, Shinji From nobody Sun Jun 7 21:18:15 2020 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 38F093A0A32 for ; Sun, 7 Jun 2020 21:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAAekNDyK6dj for ; Sun, 7 Jun 2020 21:18:12 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 25A473A0A30 for ; Sun, 7 Jun 2020 21:18:12 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id h95so5452465pje.4 for ; Sun, 07 Jun 2020 21:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=aYldVPDQQmpeFdhD3n554fd25WWJ20imgSan2SEOHko=; b=kzdtg+sy/rfSzYoj0vRAYS8TM5ub6Z8bsGgZxbmHOYUASqiOod8JVndFbs+b4KTIkd p4GnGvUmkon1BviWEdsHvEvlp/JHQOMN1hzHX8M6n7BWy5cdVyjkCSz3PeETBfERYdaC O0xf5rk4XheqR0NGIQWR3oqMbs5g09pAhGOOfxGzSNEtY3xKUs6SzMruxzOtoI+vufve wx7kLl5h7qvcLlHW/9e2qz9H+Xubnev7tIEFB2XapnIFZrtIqcYbqqybzXFcXVN6jUES XtRNuqb5CWdm7OwUDWFtvtmzE40tJOehUROS6yQseFw2QHpsWFrCpwCBwq3lvu/Ez+zU +lGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=aYldVPDQQmpeFdhD3n554fd25WWJ20imgSan2SEOHko=; b=dQzDdw5xEuNAZQhgf+w0seB7qkpOsg+phPfgzDcDMn6gQZhiES2E/UFD9Bvxzp35X+ pF9ozqYfQl2M8iPTx4LZeFeu9KBq8q4aWsj1X0WqR0JPqXZmaMZ7OsSg6UrPMiLKnP2s v5MRXB9BUqnNj4kC6T9UMO7xC75bFaDQ+7Q7HEIoHm9/d+lga3rhU9uFQ+dv+YpePoh8 xZCxV47+JFr7K364IO7OjNYeBhdLboNWb/DRuWHAwFl7BaNjoGrenVCuZiDT36U7V/IS riUwSJXKeewYE8bTjWbhJyODtQTiCFhJplmHyzzY4B3mVB9Vk0SdTqfJsOAlEDK96ZBf pePA== X-Gm-Message-State: AOAM531HKNIqqSlJ2F9LAEX6zf+qhxjs2b63gH19ga73+jOEfzfG+v9r HgaTPg3aTQiPhbd1yyPd9cQ= X-Google-Smtp-Source: ABdhPJz4Q/z4bY4JsQImXKhIGr/W58zF0L5I1dLSynxH7egc3bEoJOYhT4wz9ZM9JMzul+gktXB1CA== X-Received: by 2002:a17:902:7785:: with SMTP id o5mr16427991pll.288.1591589891508; Sun, 07 Jun 2020 21:18:11 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id a20sm5492892pff.147.2020.06.07.21.18.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 21:18:10 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Message-ID: Date: Mon, 8 Jun 2020 13:18:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 04:18:13 -0000 Hi, I think the following change is necessary. Section 8.2 says: ======================================================================== If the proxy remembers that the UAC did not support the session timer either, the proxy forwards the response upstream normally. ======================================================================== It should say: ======================================================================== If the proxy remembers that the UAC did not support the session timer either or the value of the 'refresher' parameter was 'uas', the proxy forwards the response upstream normally. ======================================================================== Regards, Shinji From nobody Sun Jun 7 23:13:48 2020 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 236273A0602 for ; Sun, 7 Jun 2020 23:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 czQBqMf4YSr8 for ; Sun, 7 Jun 2020 23:13:45 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 ABF1B3A0544 for ; Sun, 7 Jun 2020 23:13:45 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id b18so12729213oti.1 for ; Sun, 07 Jun 2020 23:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jaN+8gvaON+dw0KroNo3xYk9SVby+rt7Z//ZbZYJMoQ=; b=ATodI4qD9AuzVmkbroWkTp8kZI/xTG2D4zWzlk+5/PR9V5wEe4QJ8AM7ZRP9XvoK9w T75SWWwvaWwg6Xde6E3PybL/dem9qw08SkcjpkB5ogbqOAUBpJJ1mJcO0EIp86/aLPH+ 8rcBRUZ1S4MV/b2mUbdkECOGKSe0rZNi7QvD5m/cXhSsI1qa0171J6agJ4IBdW0gajVM ZwHkT9KnT2uBKg/i0ZFUZlRj58XpyoByFJ/aXG1c8uRnZS4l3S0OtQe4+H7jU663Vvec U2iCReP/3MeCFdNUzfH5JpwBqNDsQZ+QrW39+IXcBxutO6QBc1yuqxXHRkRIu4g15UNr 358Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jaN+8gvaON+dw0KroNo3xYk9SVby+rt7Z//ZbZYJMoQ=; b=MZN7FRR8dQcF2wgR2wYGBZ7FF4LUYs1WMeBHp/vgyyk4P3iny7WwTwYfNMotFhCiVj aAqtkQ0T+2SUdeCADVaAnZm2+gWa1sDFzL8X2AaftXezxfNNSTPZGV2PiISaeQxvzucJ 7A9c01oYE7LrgmAh+WRaRU797zzSxxmHC3weZch+RGfHvkcu8GpUAZq3Wuj9F79ZYIpi sEJLpx59z472OK2kJj72JEsASde4ypBAROmOB1QLWyxnKKHo61dEhh7TRl9styLwpVB5 qTw55YXd5En+Yaewp7QDS6ZAn6fg+eUgGGbOrPAu5gyKH0QsSnXD0dDdD7mukZsV6j6+ 3P5A== X-Gm-Message-State: AOAM532UElZ0VtPMwlbRRR9u2aLJKLTrAGtlNCtO6ofuAyQOZt/bf0vB +M+aKDKwyIrMIg7QSX6ErBGOxSMhl0c= X-Google-Smtp-Source: ABdhPJxc1eVi7l0/CMMS/asCFAdRCwzKD6iRAOKJNvR0OL6+LrZ+jWSHQJBh42xDvxwQBYmfqLCObw== X-Received: by 2002:a9d:6e8e:: with SMTP id a14mr9848294otr.52.1591596824422; Sun, 07 Jun 2020 23:13:44 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com. [209.85.167.181]) by smtp.gmail.com with ESMTPSA id d13sm520164otq.46.2020.06.07.23.13.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 23:13:43 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id s21so14251578oic.9 for ; Sun, 07 Jun 2020 23:13:43 -0700 (PDT) X-Received: by 2002:aca:d7d6:: with SMTP id o205mr9728397oig.5.1591596822681; Sun, 07 Jun 2020 23:13:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 8 Jun 2020 02:13:31 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000003dddc405a78c83fb" Archived-At: Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 06:13:47 -0000 --0000000000003dddc405a78c83fb Content-Type: text/plain; charset="UTF-8" You are most likely correct. This is a bug. _____________ Roman Shpount On Mon, Jun 8, 2020 at 12:18 AM OKUMURA Shinji wrote: > Hi, > > I think the following change is necessary. > > Section 8.2 says: > ======================================================================== > If the proxy remembers > that the UAC did not support the session timer either, the proxy > forwards the response upstream normally. > ======================================================================== > > It should say: > ======================================================================== > If the proxy remembers that the UAC did not support the session timer > either or the value of the 'refresher' parameter was 'uas', the proxy > forwards the response upstream normally. > ======================================================================== > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000003dddc405a78c83fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+WW91IGFyZSBtb3N0IGxpa2VseSBjb3JyZWN0LiBUaGlzIGlzIGEgYnVn LjxiciBjbGVhcj0iYWxsIj48ZGl2PjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWduYXR1 cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPl9fX19fX19fX19fX188YnI+Um9t YW4gU2hwb3VudDwvZGl2PjwvZGl2Pjxicj48L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIEp1biA4LCAyMDIw IGF0IDEyOjE4IEFNIE9LVU1VUkEgU2hpbmppICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi5zaGlu amlAZ21haWwuY29tIj5pZXRmLnNoaW5qaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPkhpLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGZvbGxvd2luZyBjaGFuZ2UgaXMg bmVjZXNzYXJ5Ljxicj4NCjxicj4NClNlY3Rpb24gOC4yIHNheXM6PGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPg0KwqAgwqAgSWYgdGhlIHByb3h5IHJlbWVtYmVyczxicj4NCsKgIMKgIHRoYXQgdGhl IFVBQyBkaWQgbm90IHN1cHBvcnQgdGhlIHNlc3Npb24gdGltZXIgZWl0aGVyLCB0aGUgcHJveHk8 YnI+DQrCoCDCoCBmb3J3YXJkcyB0aGUgcmVzcG9uc2UgdXBzdHJlYW0gbm9ybWFsbHkuPGJyPg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KSXQgc2hvdWxkIHNheTo8YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQrCoCDCoCBJZiB0aGUgcHJveHkgcmVtZW1iZXJzIHRoYXQgdGhlIFVBQyBkaWQg bm90IHN1cHBvcnQgdGhlIHNlc3Npb24gdGltZXI8YnI+DQrCoCDCoCBlaXRoZXIgb3IgdGhlIHZh bHVlIG9mIHRoZSAmIzM5O3JlZnJlc2hlciYjMzk7IHBhcmFtZXRlciB3YXMgJiMzOTt1YXMmIzM5 OywgdGhlIHByb3h5PGJyPg0KwqAgwqAgZm9yd2FyZHMgdGhlIHJlc3BvbnNlIHVwc3RyZWFtIG5v cm1hbGx5Ljxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU2hp bmppPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZTwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+DQo= --0000000000003dddc405a78c83fb-- From nobody Mon Jun 8 00:26:56 2020 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 2E1CC3A091E for ; Mon, 8 Jun 2020 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 D1Q-lx_vwoqo for ; Mon, 8 Jun 2020 00:26:54 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2082.outbound.protection.outlook.com [40.107.22.82]) (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 8458E3A091B for ; Mon, 8 Jun 2020 00:26:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DN5UV1jNp8/RGCPE+CMPQRg9Gz076sU7rMkYgB1zIaZ+Bv4VXktHW9uNpGULyoRluXgFV24UZcaw89l7ttgwv67tp1WVcoj5Z0nKGGENxMIa94UJ9mfLBYSWOEcjQGgsbNQtDRx/AWBxNjT+q42NuJG/IHvlQc/VIFywzL2D0ithspgZlGnPBKH0o4nsLoLBAQzB8Fd7S2+uonnv8MDxhJ+M8qYirlYVg8othQycMoL8eTBtqHt46mnDqE8rFdlvQQ8t2T0nUZ8gCnBkKOWS+ytrUipdyHgRblMK0pMGVxIY+7TWsFiosD2gLEOYeL8zt/lGVyMZTXwWt2mHujYt8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=34kemAQ6+A1Co2VzOXZIyH1352h3pG+Qpu+Vp6CdZto=; b=VLYXrbJG72N/GFCT/aYtKd2e5cD2vR6R+A87kVmzG0cpB7qb5FNi2v+iTJiB+WaQCJplrBexLnBGZEZU+gWMYPihhvtSU3MInLELR5hbXW+0K8U34gC47Wd+WR2Jk7zH+gc2piSwNh3/BGA2iEEelc0ctiBodj06qAqcsQc6fiQkrq+L3cvqTZH1CIg84IGLhDcKHNbL4zfu3YgNl6hsj41YxgJrPWx5seHqxCAwMCY2aFw50cReEYKu8JghkEAvPOXrG3WqjUjVTpbOIstFDe/skcnVvy/epTsLAmiHVcK45gcuzI+d3KuKeszsgzwAxg53g/RxBIOXrl8HlF1UKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=34kemAQ6+A1Co2VzOXZIyH1352h3pG+Qpu+Vp6CdZto=; b=mYMyfpnYeSzMbqj8h6v1DizxvtsI4cFicYvIhOAu/5LID0i/1EOmDk4EsFDHY013DkQoEbvk4Pgjmjwy9BCgsmdY3A6259tUCZZYe/iWivXvkoSK7DSD1Jmmg5vw17pgFnBt+MnzXMaKh5flwI/AnrtQAmHwnG85wvIK6PQ1Gl8= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6312.eurprd07.prod.outlook.com (2603:10a6:20b:139::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.11; Mon, 8 Jun 2020 07:26:51 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3088.016; Mon, 8 Jun 2020 07:26:51 +0000 From: Christer Holmberg To: Roman Shpount , OKUMURA Shinji CC: SIPCORE Thread-Topic: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses Thread-Index: AQHWPUvVZYbJu774rkq4zdxtk+lhpKjOPUWAgAAURGA= Date: Mon, 8 Jun 2020 07:26:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b0827b6-adec-4836-3cd8-08d80b7d4fe2 x-ms-traffictypediagnostic: AM7PR07MB6312: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WgUBsF1tY0TBDQkz5iZXN4grKdtQCAC8stak/ojsWeh+hNKHgjHK4UIcDbk1UeyZDpTLEybQLP8hH8h/P+2wLfsLuUrXRxpF4Er9U+vT3pjqnZqemq2VsRqjMdeKeXcznCRAncuszKNlss1j5YdEsOh8Xfeo1xubiTmMjZ9vbxztTzSmOlYlf7xlsPEJGbhYVKqh2kv3iPFW7Agb3+dtvB8p4Q31x21kbpqVCwcpgD6KoUzDklpEzRlg+HwWGsH2CiJXUKn6/p8v/BAkobMhbmk6a+qI1xEAsQ1UPyLO0DUwCdZ86bLVkxo/DFDiBhMWoeIUzpJd5Y6lEfwePR4BFuZJs0azHFzM3CpK1yBKK7rgPf3ayAeW3nUG3HzRPKcNtRXExEablTqYAY0YFCxQ4g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(396003)(366004)(346002)(966005)(4326008)(52536014)(5660300002)(44832011)(8936002)(9686003)(26005)(186003)(478600001)(55016002)(166002)(66574014)(8676002)(316002)(86362001)(7696005)(66476007)(66446008)(71200400001)(110136005)(6506007)(64756008)(33656002)(66556008)(53546011)(66946007)(76116006)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nnpWjBy5BB3S6evmmEwjNUiszxTqIBoNLfrRUh2taAtt/b/Qgu5u8eCIZsoUZcwisvLKcZWZP1G8lzgcbbmV4NAJ6o6hJbauKp0ye8u5g0fBlVR6FfFrAN5uPr1WrznS/7IOOe/K73JG4TMqFp6M3hRNhRHIyGpG9VbmRKIQLRHDlHdSbMwix4NzzHkvM/b7FVAKJ9LyivNaUa5/B81Z1qWvm/9MxaIh0g3nVx+bvGDADh6RE0owwdH8Hl7A0ceDuuR08VkVFGy2ozJRxYuGGYzEPRKqrjULxW5BBp0FSve7tI49V19pO+S36qCrT6DQ6ZAP2JEsiJk19ZKbGgQPHt5S+nNfTcQAB2HDK8DvZj3qyqKX5hw3i5VBtJA43LuiUKwFpuXCXBVb+8bBNx4zNZXEZLnkZ5Km/NXXdzI3RjfXDcGU7bWPeFTjPMCFzv0HmxuiNiWss485fbrR5MYE+jhYoTkijIcyZ3OB92iy/WoKl9v42xznhmPzXQB6irFw x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB701265FB8A3AC21F6859935193850AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b0827b6-adec-4836-3cd8-08d80b7d4fe2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 07:26:51.1561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rLfrO1GR+jNwhYK9Mu08V31jqeqMZQE9wZXat/YN0+GAHAFUTEOh2dYCLL3NvKJ5wOWfCml+t4x+QNupY6gr1LwcFf3gXumApSbZQB8QZNI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6312 Archived-At: Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 07:26:55 -0000 --_000_AM7PR07MB701265FB8A3AC21F6859935193850AM7PR07MB7012eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGJ1Z3MgY291bGQgYmUgcmFpc2VkIGFzIGlz c3VlcyBpbiB0aGUgYXNzb2NpYXRlZCBHaXRodWIgcmVwbywgdG8gbWFrZSBzdXJlIHdlIGtlZXAg dHJhY2sgb2YgdGhlbToNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNpcGNvcmUt NDAyOGJpcw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb21hbiBTaHBvdW50DQpTZW50OiBtYWFu YW50YWkgOC4ga2Vzw6RrdXV0YSAyMDIwIDkuMTQNClRvOiBPS1VNVVJBIFNoaW5qaSA8aWV0Zi5z aGluamlAZ21haWwuY29tPg0KQ2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFJGQzQwMjggOiBCdWcgaW4gOC4yLiBQcm9jZXNzaW5nIG9mIFJlc3Bv bnNlcw0KDQpZb3UgYXJlIG1vc3QgbGlrZWx5IGNvcnJlY3QuIFRoaXMgaXMgYSBidWcuDQpfX19f X19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0KT24gTW9uLCBKdW4gOCwgMjAyMCBhdCAxMjox OCBBTSBPS1VNVVJBIFNoaW5qaSA8aWV0Zi5zaGluamlAZ21haWwuY29tPG1haWx0bzppZXRmLnNo aW5qaUBnbWFpbC5jb20+PiB3cm90ZToNCkhpLA0KDQpJIHRoaW5rIHRoZSBmb2xsb3dpbmcgY2hh bmdlIGlzIG5lY2Vzc2FyeS4NCg0KU2VjdGlvbiA4LjIgc2F5czoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K ICAgIElmIHRoZSBwcm94eSByZW1lbWJlcnMNCiAgICB0aGF0IHRoZSBVQUMgZGlkIG5vdCBzdXBw b3J0IHRoZSBzZXNzaW9uIHRpbWVyIGVpdGhlciwgdGhlIHByb3h5DQogICAgZm9yd2FyZHMgdGhl IHJlc3BvbnNlIHVwc3RyZWFtIG5vcm1hbGx5Lg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkl0IHNob3Vs ZCBzYXk6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICBJZiB0aGUgcHJveHkgcmVtZW1iZXJzIHRoYXQg dGhlIFVBQyBkaWQgbm90IHN1cHBvcnQgdGhlIHNlc3Npb24gdGltZXINCiAgICBlaXRoZXIgb3Ig dGhlIHZhbHVlIG9mIHRoZSAncmVmcmVzaGVyJyBwYXJhbWV0ZXIgd2FzICd1YXMnLCB0aGUgcHJv eHkNCiAgICBmb3J3YXJkcyB0aGUgcmVzcG9uc2UgdXBzdHJlYW0gbm9ybWFsbHkuDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg0KUmVnYXJkcywNClNoaW5qaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0 Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== --_000_AM7PR07MB701265FB8A3AC21F6859935193850AM7PR07MB7012eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkl0IHdvdWxkIGJlIGdvb2Qg aWYgdGhlIGJ1Z3MgY291bGQgYmUgcmFpc2VkIGFzIGlzc3VlcyBpbiB0aGUgYXNzb2NpYXRlZCBH aXRodWIgcmVwbywgdG8gbWFrZSBzdXJlIHdlIGtlZXAgdHJhY2sgb2YgdGhlbTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY2Ro NHUvZHJhZnQtc2lwY29yZS00MDI4YmlzIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9naXRo dWIuY29tL2NkaDR1L2RyYWZ0LXNpcGNvcmUtNDAyOGJpczwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzdGVyPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNpcGNvcmUgJmx0O3NpcGNvcmUtYm91bmNl c0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxi PlNlbnQ6PC9iPiBtYWFuYW50YWkgOC4ga2Vzw6RrdXV0YSAyMDIwIDkuMTQ8YnI+DQo8Yj5Ubzo8 L2I+IE9LVU1VUkEgU2hpbmppICZsdDtpZXRmLnNoaW5qaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NpcGNvcmVdIFJGQzQwMjggOiBCdWcgaW4gOC4yLiBQcm9jZXNzaW5nIG9mIFJl c3BvbnNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgbW9z dCBsaWtlbHkgY29ycmVjdC4gVGhpcyBpcyBhIGJ1Zy48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f Xzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVuIDgsIDIwMjAgYXQgMTI6MTggQU0gT0tVTVVSQSBTaGlu amkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLnNoaW5qaUBnbWFpbC5jb20iPmlldGYuc2hpbmpp QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgZm9s bG93aW5nIGNoYW5nZSBpcyBuZWNlc3NhcnkuPGJyPg0KPGJyPg0KU2VjdGlvbiA4LjIgc2F5czo8 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQombmJzcDsgJm5ic3A7IElmIHRoZSBwcm94eSByZW1l bWJlcnM8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgdGhlIFVBQyBkaWQgbm90IHN1cHBvcnQgdGhl IHNlc3Npb24gdGltZXIgZWl0aGVyLCB0aGUgcHJveHk8YnI+DQombmJzcDsgJm5ic3A7IGZvcndh cmRzIHRoZSByZXNwb25zZSB1cHN0cmVhbSBub3JtYWxseS48YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQo8YnI+DQpJdCBzaG91bGQgc2F5Ojxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZuYnNw OyAmbmJzcDsgSWYgdGhlIHByb3h5IHJlbWVtYmVycyB0aGF0IHRoZSBVQUMgZGlkIG5vdCBzdXBw b3J0IHRoZSBzZXNzaW9uIHRpbWVyPGJyPg0KJm5ic3A7ICZuYnNwOyBlaXRoZXIgb3IgdGhlIHZh bHVlIG9mIHRoZSAncmVmcmVzaGVyJyBwYXJhbWV0ZXIgd2FzICd1YXMnLCB0aGUgcHJveHk8YnI+ DQombmJzcDsgJm5ic3A7IGZvcndhcmRzIHRoZSByZXNwb25zZSB1cHN0cmVhbSBub3JtYWxseS48 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClNoaW5qaTxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_AM7PR07MB701265FB8A3AC21F6859935193850AM7PR07MB7012eurp_-- From nobody Mon Jun 8 00:51:14 2020 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 988683A0957 for ; Mon, 8 Jun 2020 00:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dMRhctVzKJgG for ; Mon, 8 Jun 2020 00:51:10 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 58EDF3A0953 for ; Mon, 8 Jun 2020 00:51:10 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id t6so3661024otk.9 for ; Mon, 08 Jun 2020 00:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F5YKiZKX1TGA08vdzVpOVh3gVgRulic943F+i3rZ8T4=; b=QiX/SM7OT4HiQarVeRSsqU4fFCFOxZWE3mxyrbWHPYxLbB9qnjwSf2VZanYObcjrgy VayT9FThclFLLUeA29UopSl+2A4cLrf7RPjZHVilMJylLBjKHhWVZRv6s7U01RPdHVL8 w8/eE2Bjx8zLgcZM5aCwPLzdtxwUKG6BAu9qOEZNt3T3K6ysoWsn95/pZ05uvOM4TFrH 2Jvx+XxfNuTy+0Gofmhj8PlMpDqyBA4K15ThRtLHLZMGvVRHxEHfqRfqsmY4ZNOzbHhz rKOS0Wy4+EDBeKCvcDg7PlixMepDL8gSfqrwK2IZ7ZLUTwuheZMt3JKzPfCqxsI1KGLW 1dCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F5YKiZKX1TGA08vdzVpOVh3gVgRulic943F+i3rZ8T4=; b=k0CsLi3mjvSCHCw6MwslIbmncLc2m9PokFF96S2GyOvybxlX6upIDOXf+Pln1WjEMh bwpXaWZF5NpSiiyGHsQDaoO1U4W+e7adfgftVXnxdKoRHWribSMduMRgA/5UovuvZBmC 5GVS2Jgl0yKhOasdWMoog65d2/Sw4tUy/GSafTnIfPwGVDz6fw/X8zOD+JFZI5GfYPgA sQ2uId0/e3jNnyR08YRRImDxXgKop34IkHJ8B8qpMcq2UKxGqqS6MKsgvTv8vU8I02Va /pCCQ7yNd3xjWpIhNVFHgBPVmFmxeUXinZ5zVDf29i/UjuoPsBfzixKxGlQB95XnBWRW pWhg== X-Gm-Message-State: AOAM5325k7U3hROQFkEQ1b75md0mMKESNZVJPQwZt5NM50uAou3EvFVO eapuFON3KautxVhm0Ry5AfkMmZn5Qmw= X-Google-Smtp-Source: ABdhPJxamvXOBrSr52/tGH6r95yfGL+KCKSVrwAGp5xRO84pf58YKLpqR8LmRKG1FHwnfLDZFkWJiA== X-Received: by 2002:a05:6830:3151:: with SMTP id c17mr17383736ots.143.1591602668075; Mon, 08 Jun 2020 00:51:08 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com. [209.85.210.44]) by smtp.gmail.com with ESMTPSA id l196sm2281266oih.25.2020.06.08.00.51.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 00:51:07 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id g5so12883187otg.6 for ; Mon, 08 Jun 2020 00:51:06 -0700 (PDT) X-Received: by 2002:a9d:604e:: with SMTP id v14mr16836993otj.39.1591602666473; Mon, 08 Jun 2020 00:51:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 8 Jun 2020 03:50:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: OKUMURA Shinji , SIPCORE Content-Type: multipart/alternative; boundary="0000000000008f0ec605a78ddfb6" Archived-At: Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 07:51:13 -0000 --0000000000008f0ec605a78ddfb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Done: https://github.com/cdh4u/draft-sipcore-4028bis/issues/1 _____________ Roman Shpount On Mon, Jun 8, 2020 at 3:26 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > It would be good if the bugs could be raised as issues in the associated > Github repo, to make sure we keep track of them: > > > > https://github.com/cdh4u/draft-sipcore-4028bis > > > > Regards, > > > > Christer > > > > *From:* sipcore *On Behalf Of *Roman Shpount > *Sent:* maanantai 8. kes=C3=A4kuuta 2020 9.14 > *To:* OKUMURA Shinji > *Cc:* SIPCORE > *Subject:* Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses > > > > You are most likely correct. This is a bug. > > _____________ > Roman Shpount > > > > > > On Mon, Jun 8, 2020 at 12:18 AM OKUMURA Shinji > wrote: > > Hi, > > I think the following change is necessary. > > Section 8.2 says: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If the proxy remembers > that the UAC did not support the session timer either, the proxy > forwards the response upstream normally. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > It should say: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If the proxy remembers that the UAC did not support the session timer > either or the value of the 'refresher' parameter was 'uas', the proxy > forwards the response upstream normally. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --0000000000008f0ec605a78ddfb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Done:=C2=A0 https:/= /github.com/cdh4u/draft-sipcore-4028bis/issues/1=C2=A0=C2=A0
_____________
Roman Shpount


On Mon, Jun = 8, 2020 at 3:26 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

It would be good if the bugs co= uld be raised as issues in the associated Github repo, to make sure we keep= track of them:

=C2=A0

https://github.com/cdh4u/draf= t-sipcore-4028bis

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Roman Shpount
Sent: maanantai 8. kes=C3=A4kuuta 2020 9.14
To: OKUMURA Shinji <ietf.shinji@gmail.com>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses=

=C2=A0

You are most likely correct. This is a bug.

_____________
Roman Shpount

=C2=A0

=C2=A0

On Mon, Jun 8, 2020 at 12:18 AM OKUMURA Shinji <<= a href=3D"mailto:ietf.shinji@gmail.com" target=3D"_blank">ietf.shinji@gmail= .com> wrote:

Hi,

I think the following change is necessary.

Section 8.2 says:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 If the proxy remembers
=C2=A0 =C2=A0 that the UAC did not support the session timer either, the pr= oxy
=C2=A0 =C2=A0 forwards the response upstream normally.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

It should say:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 If the proxy remembers that the UAC did not support the sessi= on timer
=C2=A0 =C2=A0 either or the value of the 'refresher' parameter was = 'uas', the proxy
=C2=A0 =C2=A0 forwards the response upstream normally.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Regards,
Shinji

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

--0000000000008f0ec605a78ddfb6-- From nobody Mon Jun 8 01:05:31 2020 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 E3BEB3A0972 for ; Mon, 8 Jun 2020 01:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yMsUtstN8jeN for ; Mon, 8 Jun 2020 01:05:28 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 479903A0971 for ; Mon, 8 Jun 2020 01:05:28 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id x202so14459174oix.11 for ; Mon, 08 Jun 2020 01:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9GqYOpWP3Z8zu28w32juvN6GK5W3663i5J4/ZP23jTk=; b=FxUDwzviSkPwTOBiYDSXHE24/gyNDeo89Exm+MOKWfREknKmZJcF5rMwy8zafHsnUR WwWSu9oCJCAck7ZcByVEcv26VYGLHwmZNoYo/dcWk6SE9ipTVKHhgAmUo4S/CDnfwUBa J5zEgwPS313tBYAWGUH2EPNmg8iQdZ9lut9HxYDzMPEapyqta7o8RQ4+65qv2ZFWT2rV OD+VvYKj3YHqfkxQiqfks40Yk7HbERyt4WgE+Rc5PHoesdpPyUw81f7wp1+dZsj0pMPa lHl7vh113EEUYipdLYKJxfCU7SN6cr5uNnfF+7gv7kuNIGIeoimyjaK+J9r0dnH9ZQ6Q qgaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9GqYOpWP3Z8zu28w32juvN6GK5W3663i5J4/ZP23jTk=; b=k8Z+DGvZW/ZYxNccbpxKDvSxOEUW7fN5c8RXT2JRfb416wDfLqCESvjSLQ46miyKwa lDZpDTlgmh+5C8xIHQAYuPPUssC0tRGlrGa6qkJYkcomnjh/TkgxAPRhEOXUlV4K/72v CFbFW4tUNRwmABEtTvLSvDyexL9tCHgW41CLs73kqXZpcEZuANPe/NiSPZbmB7F+Ihx/ LX3yPTpDedu9Ob+qusSkneKpr4KwSEWdA+Q+ADDHqLvb4tpZlqaRYubZrV/paqE36J1n jiKwLft4rf04UlEwKn2mmglxD26GwMVW0wdar/IDDmW2+wc/2QbQtWNDlaH2IE7RseK4 3Yuw== X-Gm-Message-State: AOAM532mOewRC/HdMnnItallvjHpXp2/xZFPUKpUm2IXHqaFxY+wNyaR 9nYDKV0z2BZ6nckTSrekKx29aWTeDVc= X-Google-Smtp-Source: ABdhPJw4mE2vCpKJXDrHvZGq73gmQT+wXeEihgHQTxry/Nz4aPwL+xBU1wXIsa3k1FLMu9tIwoFp7g== X-Received: by 2002:aca:5bc3:: with SMTP id p186mr9221275oib.59.1591603525211; Mon, 08 Jun 2020 01:05:25 -0700 (PDT) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com. [209.85.210.46]) by smtp.gmail.com with ESMTPSA id e68sm1383504ote.56.2020.06.08.01.05.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 01:05:24 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id m2so12900492otr.12 for ; Mon, 08 Jun 2020 01:05:23 -0700 (PDT) X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr16057383otr.13.1591603523251; Mon, 08 Jun 2020 01:05:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 8 Jun 2020 04:05:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000a0758205a78e120c" Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 08:05:30 -0000 --000000000000a0758205a78e120c Content-Type: text/plain; charset="UTF-8" Shinji, This seems like a clarification, not a correction. I think it only should be addressed if there are known issues caused by this. _____________ Roman Shpount On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji wrote: > HI, > > ======================================================================== > 7.4. Generating Subsequent Session Refresh Requests > The value of the Min-SE header field present in a session refresh > request MUST be the largest value among all Min-SE header field > values returned in all 422 responses or received in session refresh > requests, on the same dialog, if a dialog has been established. If > no dialog has been established, the Min-SE header field value is set > to the largest value among all Min-SE header field values returned in > all 422 responses for an INVITE request with the same Call-ID. A > result of this rule is that the maximum value of the Min-SE is > effectively 'cleared' once the dialog is established, and from that > point on, only the values from proxies known to be on the proxy path > will end up being used. > ======================================================================== > > My interpretation is as shown in the figure below. > > Alice Proxy P1 > |(1) INVITE | > |SE: 1200 | > |MSE: 300 | > |----------->| <-- initial MSE is 300 > |(2) 422 | > |MSE: 900 | > |<-----------| <-- MSE is set to 900 > |(3) ACK | > |----------->| > |(4) INVITE | > |SE:1200 | > |MSE:900 | > |----------->| > |(5) 200 OK | > |SE:900 | > |<-----------| <-- dialog is established and MSE is cleared > |(6) ACK | > |----------->| > |(7) UPDATE | > |SE:900 | > |MSE:300 | > |----------->| <-- MSE is 300 > > In order to understand this description clearly, I think it is necessary > to show concrete examples. And when an early dialog is established, > another examples is necessary. > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000a0758205a78e120c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

This seems like a clarification= , not a correction. I think it only should be addressed if there are known = issues caused by this.
_____________
Roman Shpo= unt


On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji <= ietf.shinji@gmail.com> wrot= e:
HI,

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
7.4.=C2=A0 Generating Subsequent Session Refresh Requests
=C2=A0 =C2=A0 The value of the Min-SE header field present in a session ref= resh
=C2=A0 =C2=A0 request MUST be the largest value among all Min-SE header fie= ld
=C2=A0 =C2=A0 values returned in all 422 responses or received in session r= efresh
=C2=A0 =C2=A0 requests, on the same dialog, if a dialog has been establishe= d.=C2=A0 If
=C2=A0 =C2=A0 no dialog has been established, the Min-SE header field value= is set
=C2=A0 =C2=A0 to the largest value among all Min-SE header field values ret= urned in
=C2=A0 =C2=A0 all 422 responses for an INVITE request with the same Call-ID= .=C2=A0 A
=C2=A0 =C2=A0 result of this rule is that the maximum value of the Min-SE i= s
=C2=A0 =C2=A0 effectively 'cleared' once the dialog is established,= and from that
=C2=A0 =C2=A0 point on, only the values from proxies known to be on the pro= xy path
=C2=A0 =C2=A0 will end up being used.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My interpretation is as shown in the figure below.

=C2=A0 =C2=A0 Alice=C2=A0 =C2=A0 =C2=A0 Proxy P1
=C2=A0 =C2=A0 =C2=A0 |(1) INVITE=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |SE: 1200=C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |MSE: 300=C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |----------->|=C2=A0 =C2=A0<-- initial MSE is 30= 0
=C2=A0 =C2=A0 =C2=A0 |(2) 422=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |MSE: 900=C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |<-----------|=C2=A0 =C2=A0<-- MSE is set to 900=
=C2=A0 =C2=A0 =C2=A0 |(3) ACK=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |----------->|
=C2=A0 =C2=A0 =C2=A0 |(4) INVITE=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |SE:1200=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |MSE:900=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |----------->|
=C2=A0 =C2=A0 =C2=A0 |(5) 200 OK=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |SE:900=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |<-----------|=C2=A0 =C2=A0<-- dialog is establi= shed and MSE is cleared
=C2=A0 =C2=A0 =C2=A0 |(6) ACK=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |----------->|
=C2=A0 =C2=A0 =C2=A0 |(7) UPDATE=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |SE:900=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |MSE:300=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |----------->|=C2=A0 =C2=A0<-- MSE is 300

In order to understand this description clearly, I think it is necessary to show concrete examples. And when an early dialog is established,
another examples is necessary.

Regards,
Shinji

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000a0758205a78e120c-- From nobody Mon Jun 8 01:19:41 2020 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 74C3A3A09AB for ; Mon, 8 Jun 2020 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VqtqGZuZqlIH for ; Mon, 8 Jun 2020 01:19:38 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 61DA73A0994 for ; Mon, 8 Jun 2020 01:19:38 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 97so1571784otg.3 for ; Mon, 08 Jun 2020 01:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k3XjWPTRd3kcunwiNWtpLBnURkoiSv6I1Z6T9sJz45E=; b=kGSKLZtwM2J+26kmQdxkKk/qL4ZdWN9xNxjdUsYy3i4prlQhP9iaTwEY4XwCOhgqkZ 8Lc0P1I0Rlgfv0HSh1RSZqpzfKKYh6CeQJYm7l/RIMTECjC8RTVrHm+iG3yJWTPDpSsc nBIJIbCYo5otmzdoZFCipbylUpuDNw1EHvHBmsA938+9nq/yCRBQZ8G92rugIp6T2Qr3 A7cTTe/FT1eQzdcIsRe45hel6wRF6wYEmk/QPO4In+wGIRjYSkbLn6mmtHNXbCZFe0mh RmNv5tdKb97AST/qsjyd/2li+PxJrWiXVkSPuqLbxM1KotMqUuSahB5bGqVtOP7iQ7Rh mhWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k3XjWPTRd3kcunwiNWtpLBnURkoiSv6I1Z6T9sJz45E=; b=fr8NmUT9Obro1dCabYyWce405n6xb9/0UqspOCkCxGFczwFBL56ScSN5dWKSuXFKqf FGbiL4/vzkuDlhVxIBZzEIxujSBwzX+QfvDDLD4Qr6lodNBIR3bjTNq50qvwW0wMXS1O pU6wioIFE3K4EXPH1ErhoVjuXIYIzezyg5xl107E5iojORyW4GtX475Fff8YrkyKvBRQ gQnDQiCXGJZsJEY4nBjJhyMSakNBazxJ5T2NpdCRMGpAcJUifPCAyjl8EToeLZDcpEKM fcRVo88H4MCLkFV/EzW+O8xQMpWC8viK1zpiuUMOQhk8frR1l+jQK7kqDWWlQiNfw1fr BUYg== X-Gm-Message-State: AOAM5300IwCj3ofMitY5pwqOKNNKGHGmnFOc0gtedntwVMtemxfOgrhk Ahtu7zxgP3YFXcrOr4/pA8FEsFZaFxU= X-Google-Smtp-Source: ABdhPJwZu9NGM5ANU2f32cqDfjHc7LdsQNV6yJsZ4oonh+LW+cIdpUeOO3kVon/Mkmbl/vA189ZuVA== X-Received: by 2002:a9d:7f8c:: with SMTP id t12mr14303931otp.66.1591604376897; Mon, 08 Jun 2020 01:19:36 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id x7sm2172781ooj.16.2020.06.08.01.19.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 01:19:36 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id k15so12962262otp.8 for ; Mon, 08 Jun 2020 01:19:35 -0700 (PDT) X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr16087721otr.13.1591604374982; Mon, 08 Jun 2020 01:19:34 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> In-Reply-To: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> From: Roman Shpount Date: Mon, 8 Jun 2020 04:19:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000064d5be05a78e45ad" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 08:19:40 -0000 --00000000000064d5be05a78e45ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Shinji, My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests. Best Regards, _____________ Roman Shpount On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji wrote= : > Hi, > > A 200 response has no Min-SE header. > > My suggestion is below. > > In this case, the UAC and proxies should follow the procedures defined > in section 7.2 and 8.2 as if the Session-Expires header field were not > in the 2xx response. > > Regards, > Shinji > > On 2020/06/05 18:35, Roman Shpount wrote: > > Proxy, if it receives a 2xx response with Min-SE header set to a value > > lower then Min-SE set by the proxy in the corresponding request, should > > increase Min-SE to the desired proxy value. > > > > UAC, if it receives a 2xx response with Session-Expires set to a value > > below Min-SE in the response or original request from the UAC. should > > immediately terminate a call. > > > > Unfortunately, proxy has no graceful way to terminate a call, so if bot= h > > UAC and UAS are rogue, this will result in frequent session refresh > > transactions. > > > > In practice, this is not an issue, since proxy, when communicating with > > untrusted end points, typically have a some sort of dynamic rate limite= r > to > > prevent denial of service attacks such as opensips PIKE module ( > > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to > > efficiently drop SIP message from badly behaving clients. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg > 40ericsson.com@dmarc.ietf.org> wrote: > > > >> Hi, > >> > >> If what you describe is a technical bug that causes interoperability > >> problems, then it is within the scope. > >> > >> However, if there is a rogue UAS, the UAC can simply terminate the > session. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> -----Original Message----- > >> From: OKUMURA Shinji > >> Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34 > >> To: sipcore@ietf.org > >> Cc: Christer Holmberg > >> Subject: RFC4028 : bug in 11 Security Considerations > >> > >> Hi, > >> > >> 11. Security Considerations > >> Next, consider the case of a rogue UAS that wishes to force a UAC > to > >> generate refreshes at a rapid rate. In that case, the UAC has to > >> support session timer. The initial INVITE arrives at the rogue > UAS, > >> which returns a 2xx with a very small session interval. The UAC > uses > >> this timer and quickly sends a refresh. Section 7.4 requires tha= t > >> the UAC copy the current session interval into the Session-Expire= s > >> header field in the request. This enables the proxies to see the > >> current value. The proxies will reject this request and provide = a > >> Min-SE with a higher minimum, which the UAC will then use. Note, > >> that if the proxies did not reject the request, but rather proxie= d > >> the request with a Min-SE header field, an attack would still be > >> possible. The UAS could discard this header field in a 2xx > response > >> and force the UAC to continue to generate rapid requests. > >> > >> If the rogue UAS returns again a 2xx with a very small session interva= l, > >> the attack will continue. To prevent this case, I think the UAC and > proxies > >> SHOULD make sure that the SE-value and MSE-value in the response are > >> greater than or equal to the MSE-value in a sent request. And ... what > >> should the UAC and proxies do? Should they modify the response? > >> > >> Is this included in the scope of the bis? > >> > >> Regards, > >> Shinji > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > --00000000000064d5be05a78e45ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

My instinct=C2=A0would be to al= low Session-Expires header to pass through even if it is below Min-SE value= , and then let either UAC disconnect the call or denial of service filter d= o its job and drop the session if it starts sending too many requests.

Best Regards,
_____________Roman Shpount


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 5, 2020 at 9:26 AM OKUMURA= Shinji <ietf.shinji@gmail.com<= /a>> wrote:
H= i,

A 200 response has no Min-SE header.

My suggestion is below.

In this case, the UAC and proxies should follow the procedures defined
in section 7.2 and 8.2 as if the Session-Expires header field were not
in the 2xx response.

Regards,
Shinji

On 2020/06/05 18:35, Roman Shpount wrote:
> Proxy, if it receives a 2xx response with Min-SE header set to a value=
> lower then Min-SE set by the proxy in the corresponding request, shoul= d
> increase Min-SE to the desired proxy value.
>
> UAC, if it receives a 2xx response with Session-Expires set to a value=
> below Min-SE in the response or original request from the UAC. should<= br> > immediately terminate a call.
>
> Unfortunately, proxy has no graceful way to terminate a call, so if bo= th
> UAC and UAS are rogue, this will result in frequent session refresh > transactions.
>
> In practice, this is not an issue, since proxy, when communicating wit= h
> untrusted end points, typically have a some sort of dynamic rate limit= er to
> prevent denial of service attacks such as opensips PIKE module (
> https://opensips.org/docs/modules/3.1.x/pike.h= tml ) , which are used to
> efficiently drop SIP message from badly behaving clients.
>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg <christer.holmberg= =3D
> 40e= ricsson.com@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> If what you describe is a technical bug that causes interoperabili= ty
>> problems, then it is within the scope.
>>
>> However, if there is a rogue UAS, the UAC can simply terminate the= session.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> -----Original Message-----
>> From: OKUMURA Shinji <ietf.shinji@gmail.com>
>> Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34
>> To: sipcore@= ietf.org
>> Cc: Christer Holmberg <christer.holmberg@ericsson.com>
>> Subject: RFC4028 : bug in 11 Security Considerations
>>
>> Hi,
>>
>> 11.=C2=A0 Security Considerations
>>=C2=A0 =C2=A0 =C2=A0 Next, consider the case of a rogue UAS that wi= shes to force a UAC to
>>=C2=A0 =C2=A0 =C2=A0 generate refreshes at a rapid rate.=C2=A0 In t= hat case, the UAC has to
>>=C2=A0 =C2=A0 =C2=A0 support session timer.=C2=A0 The initial INVIT= E arrives at the rogue UAS,
>>=C2=A0 =C2=A0 =C2=A0 which returns a 2xx with a very small session = interval.=C2=A0 The UAC uses
>>=C2=A0 =C2=A0 =C2=A0 this timer and quickly sends a refresh.=C2=A0 = Section 7.4 requires that
>>=C2=A0 =C2=A0 =C2=A0 the UAC copy the current session interval into= the Session-Expires
>>=C2=A0 =C2=A0 =C2=A0 header field in the request.=C2=A0 This enable= s the proxies to see the
>>=C2=A0 =C2=A0 =C2=A0 current value.=C2=A0 The proxies will reject t= his request and provide a
>>=C2=A0 =C2=A0 =C2=A0 Min-SE with a higher minimum, which the UAC wi= ll then use.=C2=A0 Note,
>>=C2=A0 =C2=A0 =C2=A0 that if the proxies did not reject the request= , but rather proxied
>>=C2=A0 =C2=A0 =C2=A0 the request with a Min-SE header field, an att= ack would still be
>>=C2=A0 =C2=A0 =C2=A0 possible.=C2=A0 The UAS could discard this hea= der field in a 2xx response
>>=C2=A0 =C2=A0 =C2=A0 and force the UAC to continue to generate rapi= d requests.
>>
>> If the rogue UAS returns again a 2xx with a very small session int= erval,
>> the attack will continue. To prevent this case, I think the UAC an= d proxies
>> SHOULD make sure that the SE-value and MSE-value in the response a= re
>> greater than or equal to the MSE-value in a sent request. And ... = what
>> should the UAC and proxies do? Should they modify the response? >>
>> Is this included in the scope of the bis?
>>
>> Regards,
>> Shinji
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>
--00000000000064d5be05a78e45ad-- From nobody Mon Jun 8 02:13:41 2020 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 1858E3A0486 for ; Mon, 8 Jun 2020 02:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To1ztzk_iDxV for ; Mon, 8 Jun 2020 02:13:37 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 B9C373A045B for ; Mon, 8 Jun 2020 02:13:37 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 185so8454884pgb.10 for ; Mon, 08 Jun 2020 02:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZIhoxccdCaGQ/X9zm/IBzOxs/yxt4G/hexnWbcR7Zz8=; b=chwVn8KbqGmi7glvMjfvde45nQgjXNtqfyxHkMzSdLESqzWuNXgiSHJpKHA/hvKaPb ndPznWs6ivpZlJIGPsH6lDAYvh7nKazEQ5Rum5WK60YIrOYeZHl/eWrFLrRY//MvtARy ZOmo6XwurSYM/GUvgEVYWHBuyTSX34/EEGwf0hpoXPegg9sEwuhCc/vTlCKc/41d9GjL WkvA33LajRo4bXprQ1/5LBHFHCu25LJjUWqEAm6VIfl1BdUFQfnFDUMFhTTLTB9qpSrc pt//AuMMMrNdclYxnn+ity1XKtpAlaZs4Il1lZdZle1ACaoNbf7eqKTj5wSkQ4FpruiL U/HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZIhoxccdCaGQ/X9zm/IBzOxs/yxt4G/hexnWbcR7Zz8=; b=G1GB9m8ktdm5Jq58jF00W08KjdSsrQT2gudGi64uYEPNLBWjVT/VspdFF5/GzLZPfw htDsuz7AT9/orQ2lGqnv2ldcr/ZV944HvbFtLkQrj9pBr5kv9XBgssGJlt7YyquPfqBA y2UlkI0PQxHxUh+C8EwzRTmcv9/LzWEnwtlw+Q4dd1GXqrcnXTd4anrUz8hbuY1HUnng geNvqXbLUOUaGVvKDNfC4kACaeOLe4D8FERMFVLkoim/TTbmsgMQayQO1eXfxcOlyk4b G4Eif9w4Cb5EqRywe9aZKmOQCOMHRyJIIT1oULRe+B6au6xhUQ/1MTtyLp73uwJ3yX+R uF4w== X-Gm-Message-State: AOAM533HHC6BRKaebQeQGNJnNN2gN5XLPuEXST8tg+jniCBbBEh1/oI5 iOewzfmjwYzwHy9IbGWzrng= X-Google-Smtp-Source: ABdhPJw+ymQiHL256CFCQ0vSeYh13Ybl7O7tJbnX+BOyAAXl5Qnl18PJS49TaE0gunGzvVrVZhDgWw== X-Received: by 2002:a62:8703:: with SMTP id i3mr20714588pfe.212.1591607616944; Mon, 08 Jun 2020 02:13:36 -0700 (PDT) Received: from [192.168.1.127] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 77sm6677307pfu.139.2020.06.08.02.13.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 02:13:36 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount , Christer Holmberg References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> From: OKUMURA Shinji Message-ID: <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> Date: Mon, 8 Jun 2020 18:13:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 09:13:39 -0000 Hi, Sometimes only a proxy can notice the problem. If the value returned by a UAS is fine for the UAC, the UAC does not notice the problem. Regards, Shinji On 2020/06/08 17:19, Roman Shpount wrote: > Shinji, > > My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests. > > Best Regards, > _____________ > Roman Shpount > > > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji > wrote: > > Hi, > > A 200 response has no Min-SE header. > > My suggestion is below. > > In this case, the UAC and proxies should follow the procedures defined > in section 7.2 and 8.2 as if the Session-Expires header field were not > in the 2xx response. > > Regards, > Shinji > > On 2020/06/05 18:35, Roman Shpount wrote: > > Proxy, if it receives a 2xx response with Min-SE header set to a value > > lower then Min-SE set by the proxy in the corresponding request, should > > increase Min-SE to the desired proxy value. > > > > UAC, if it receives a 2xx response with Session-Expires set to a value > > below Min-SE in the response or original request from the UAC. should > > immediately terminate a call. > > > > Unfortunately, proxy has no graceful way to terminate a call, so if both > > UAC and UAS are rogue, this will result in frequent session refresh > > transactions. > > > > In practice, this is not an issue, since proxy, when communicating with > > untrusted end points, typically have a some sort of dynamic rate limiter to > > prevent denial of service attacks such as opensips PIKE module ( > > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to > > efficiently drop SIP message from badly behaving clients. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg > 40ericsson.com@dmarc.ietf.org > wrote: > > > >> Hi, > >> > >> If what you describe is a technical bug that causes interoperability > >> problems, then it is within the scope. > >> > >> However, if there is a rogue UAS, the UAC can simply terminate the session. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> -----Original Message----- > >> From: OKUMURA Shinji > > >> Sent: perjantai 5. kesäkuuta 2020 10.34 > >> To: sipcore@ietf.org > >> Cc: Christer Holmberg > > >> Subject: RFC4028 : bug in 11 Security Considerations > >> > >> Hi, > >> > >> 11.  Security Considerations > >>      Next, consider the case of a rogue UAS that wishes to force a UAC to > >>      generate refreshes at a rapid rate.  In that case, the UAC has to > >>      support session timer.  The initial INVITE arrives at the rogue UAS, > >>      which returns a 2xx with a very small session interval.  The UAC uses > >>      this timer and quickly sends a refresh.  Section 7.4 requires that > >>      the UAC copy the current session interval into the Session-Expires > >>      header field in the request.  This enables the proxies to see the > >>      current value.  The proxies will reject this request and provide a > >>      Min-SE with a higher minimum, which the UAC will then use.  Note, > >>      that if the proxies did not reject the request, but rather proxied > >>      the request with a Min-SE header field, an attack would still be > >>      possible.  The UAS could discard this header field in a 2xx response > >>      and force the UAC to continue to generate rapid requests. > >> > >> If the rogue UAS returns again a 2xx with a very small session interval, > >> the attack will continue. To prevent this case, I think the UAC and proxies > >> SHOULD make sure that the SE-value and MSE-value in the response are > >> greater than or equal to the MSE-value in a sent request. And ... what > >> should the UAC and proxies do? Should they modify the response? > >> > >> Is this included in the scope of the bis? > >> > >> Regards, > >> Shinji > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > From nobody Mon Jun 8 13:49:54 2020 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 DF2683A0FE9 for ; Mon, 8 Jun 2020 13:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WgGpvP1haUkP for ; Mon, 8 Jun 2020 13:49:50 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 B67D03A08CF for ; Mon, 8 Jun 2020 13:49:50 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id b8so16673514oic.1 for ; Mon, 08 Jun 2020 13:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tWQakaBJ/PDwBCnFjdi3kwA8M3pyu7bs9uQMinuvZQY=; b=SgcLELOFGNaNELgOE3+DX/ol63ZQfnAb6IDYaCmKPPhltPmGfMZ0gpHgHGXXQYAtgC o5BuQGb59vl3II5I4FuuDITKWadv/Jd6cD3cECRVcFjmkSHRWkmpXkqDtfD6PcLFjUcv D2Ma35ScP5pyTnOEbrXm2Nv0kHQJEl12DjCNgZy7Su3AhOefQ+KZqS77FSZVOGPo4pca oF3XcE0ObXGSudQTsNMryR7WEtNl+hMHuM/vCMvWkAeAeoOEXxQOgaIrSO3zgxlZAf7c //jWMiJXWvNEomriBH1BwHDQfFA/Iad3AT3Le79fZqUzUr5nD9HhLk2TYhiTjWy0Ra4L k4Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tWQakaBJ/PDwBCnFjdi3kwA8M3pyu7bs9uQMinuvZQY=; b=cgkbHN12f0MagX1fTCRDbc9pN1ya3r1nwmR7G4zqUM5mUuXi0Vy5yR83gspJH57SRO 5YiWFVM2ffcKoRFAM5CSypttklnBu9MJ+539jI190lSYfTzU1NVAXCizv9byHD+GCkU8 cSkcQvfY9DY6ni1suOia2C2Wwiopdk1ebAGO2jTSfA5mIDnXoaFehWSPXFJ59Ir+tC17 /cEuPJTGbZHrtsoLkqOUOVQ6zL2sZa/+AILAqkX5JgW8t4a8Kfwz80o2L/OpQOtc4ISy fy6LOBENggXgRMWuqTOGDnnqBA/vmSLTm7d9UpHmWY0XJMZgV5+US4i2+GzMSIxyB1Cu m7iQ== X-Gm-Message-State: AOAM5318Wwa9EapwzL41cXTL+kOiWLOgIdiGZugbY/sE3glAUDe4fxTe tBj/TIt1U+xhMR4VLyOEq2dYhghMNOE= X-Google-Smtp-Source: ABdhPJyQomhsq8XDGLoTBjFvvNhO1M2OWgJAu8O8MnqVy4R7W6/DQ01jZq/wVKnTrQu//TSIocxjPQ== X-Received: by 2002:aca:cc8b:: with SMTP id c133mr997684oig.5.1591649388728; Mon, 08 Jun 2020 13:49:48 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com. [209.85.167.174]) by smtp.gmail.com with ESMTPSA id 66sm1994329oid.2.2020.06.08.13.49.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 13:49:47 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id a3so4657833oid.4 for ; Mon, 08 Jun 2020 13:49:46 -0700 (PDT) X-Received: by 2002:aca:d7d6:: with SMTP id o205mr979473oig.5.1591649386524; Mon, 08 Jun 2020 13:49:46 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> In-Reply-To: <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> From: Roman Shpount Date: Mon, 8 Jun 2020 16:49:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" , Christer Holmberg Content-Type: multipart/alternative; boundary="0000000000004a751105a798c091" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 20:49:53 -0000 --0000000000004a751105a798c091 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Shinji, Yes, only proxy is going to notice the problem, but since proxy needs to deal with denial of service attacks anyway, it will deal with clients that set Session-Timer to a value which is too small. My view is that Min-SE is advisory. UA can disregard both Min-SE and Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy would need to gracefully deal with it. We can update security considerations to mention this, but once again, unless this is causing known interop issues, I would prefer not to touch this. Best Regards, _____________ Roman Shpount On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji wrote= : > Hi, > > Sometimes only a proxy can notice the problem. If the value returned by a > UAS is fine for the UAC, the UAC does not notice the problem. > > Regards, > Shinji > > On 2020/06/08 17:19, Roman Shpount wrote: > > Shinji, > > > > My instinct would be to allow Session-Expires header to pass through > even if it is below Min-SE value, and then let either UAC disconnect the > call or denial of service filter do its job and drop the session if it > starts sending too many requests. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji > wrote: > > > > Hi, > > > > A 200 response has no Min-SE header. > > > > My suggestion is below. > > > > In this case, the UAC and proxies should follow the procedures > defined > > in section 7.2 and 8.2 as if the Session-Expires header field were > not > > in the 2xx response. > > > > Regards, > > Shinji > > > > On 2020/06/05 18:35, Roman Shpount wrote: > > > Proxy, if it receives a 2xx response with Min-SE header set to a > value > > > lower then Min-SE set by the proxy in the corresponding request, > should > > > increase Min-SE to the desired proxy value. > > > > > > UAC, if it receives a 2xx response with Session-Expires set to a > value > > > below Min-SE in the response or original request from the UAC. > should > > > immediately terminate a call. > > > > > > Unfortunately, proxy has no graceful way to terminate a call, so > if both > > > UAC and UAS are rogue, this will result in frequent session > refresh > > > transactions. > > > > > > In practice, this is not an issue, since proxy, when > communicating with > > > untrusted end points, typically have a some sort of dynamic rate > limiter to > > > prevent denial of service attacks such as opensips PIKE module ( > > > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are > used to > > > efficiently drop SIP message from badly behaving clients. > > > > > > Best Regards, > > > _____________ > > > Roman Shpount > > > > > > > > > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg > > > 40ericsson.com@dmarc.ietf.org 40ericsson.com@dmarc.ietf.org>> wrote: > > > > > >> Hi, > > >> > > >> If what you describe is a technical bug that causes > interoperability > > >> problems, then it is within the scope. > > >> > > >> However, if there is a rogue UAS, the UAC can simply terminate > the session. > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: OKUMURA Shinji ietf.shinji@gmail.com>> > > >> Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34 > > >> To: sipcore@ietf.org > > >> Cc: Christer Holmberg christer.holmberg@ericsson.com>> > > >> Subject: RFC4028 : bug in 11 Security Considerations > > >> > > >> Hi, > > >> > > >> 11. Security Considerations > > >> Next, consider the case of a rogue UAS that wishes to forc= e > a UAC to > > >> generate refreshes at a rapid rate. In that case, the UAC > has to > > >> support session timer. The initial INVITE arrives at the > rogue UAS, > > >> which returns a 2xx with a very small session interval. > The UAC uses > > >> this timer and quickly sends a refresh. Section 7.4 > requires that > > >> the UAC copy the current session interval into the > Session-Expires > > >> header field in the request. This enables the proxies to > see the > > >> current value. The proxies will reject this request and > provide a > > >> Min-SE with a higher minimum, which the UAC will then use. > Note, > > >> that if the proxies did not reject the request, but rather > proxied > > >> the request with a Min-SE header field, an attack would > still be > > >> possible. The UAS could discard this header field in a 2x= x > response > > >> and force the UAC to continue to generate rapid requests. > > >> > > >> If the rogue UAS returns again a 2xx with a very small session > interval, > > >> the attack will continue. To prevent this case, I think the UAC > and proxies > > >> SHOULD make sure that the SE-value and MSE-value in the respons= e > are > > >> greater than or equal to the MSE-value in a sent request. And > ... what > > >> should the UAC and proxies do? Should they modify the response? > > >> > > >> Is this included in the scope of the bis? > > >> > > >> Regards, > > >> Shinji > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > > > > --0000000000004a751105a798c091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

Yes, only proxy is going to not= ice the problem, but since proxy needs to deal with denial of service attac= ks anyway, it will deal with clients that set Session-Timer to a value whic= h is too small.

My view is that Min-SE is advisory= . UA can disregard both Min-SE and Session-Expires and send re-INVITE or UP= DATE at any rate it wants. Proxy would need to gracefully deal with it. We = can update security considerations to mention this, but once again, unless = this is causing known interop issues, I would prefer not to touch this.

Best Regards,
_____________<= br>Roman Shpount


=
On Mon, Jun 8, 2020 at 5:13 AM OKUMUR= A Shinji <ietf.shinji@gmail.com= > wrote:
= Hi,

Sometimes only a proxy can notice the problem. If the value returned by a U= AS is fine for the UAC, the UAC does not notice the problem.

Regards,
Shinji

On 2020/06/08 17:19, Roman Shpount wrote:
> Shinji,
>
> My instinct=C2=A0would be to allow Session-Expires header to pass thro= ugh even if it is below Min-SE value, and then let either UAC disconnect th= e call or denial of service filter do its job and drop the session if it st= arts sending too many requests.
>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <ietf.shinji@gmail.com <mailto= :ietf.shinji@gma= il.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0A 200 response has no Min-SE header.
>
>=C2=A0 =C2=A0 =C2=A0My suggestion is below.
>
>=C2=A0 =C2=A0 =C2=A0In this case, the UAC and proxies should follow the= procedures defined
>=C2=A0 =C2=A0 =C2=A0in section 7.2 and 8.2 as if the Session-Expires he= ader field were not
>=C2=A0 =C2=A0 =C2=A0in the 2xx response.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Shinji
>
>=C2=A0 =C2=A0 =C2=A0On 2020/06/05 18:35, Roman Shpount wrote:
>=C2=A0 =C2=A0 =C2=A0 > Proxy, if it receives a 2xx response with Min= -SE header set to a value
>=C2=A0 =C2=A0 =C2=A0 > lower then Min-SE set by the proxy in the cor= responding request, should
>=C2=A0 =C2=A0 =C2=A0 > increase Min-SE to the desired proxy value. >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > UAC, if it receives a 2xx response with Sessi= on-Expires set to a value
>=C2=A0 =C2=A0 =C2=A0 > below Min-SE in the response or original requ= est from the UAC. should
>=C2=A0 =C2=A0 =C2=A0 > immediately terminate a call.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Unfortunately, proxy has no graceful way to t= erminate a call, so if both
>=C2=A0 =C2=A0 =C2=A0 > UAC and UAS are rogue, this will result in fr= equent session refresh
>=C2=A0 =C2=A0 =C2=A0 > transactions.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > In practice, this is not an issue, since prox= y, when communicating with
>=C2=A0 =C2=A0 =C2=A0 > untrusted end points, typically have a some s= ort of dynamic rate limiter to
>=C2=A0 =C2=A0 =C2=A0 > prevent denial of service attacks such as ope= nsips PIKE module (
>=C2=A0 =C2=A0 =C2=A0 > https://opensips.org/= docs/modules/3.1.x/pike.html ) , which are used to
>=C2=A0 =C2=A0 =C2=A0 > efficiently drop SIP message from badly behav= ing clients.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Best Regards,
>=C2=A0 =C2=A0 =C2=A0 > _____________
>=C2=A0 =C2=A0 =C2=A0 > Roman Shpount
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmb= erg <christer.holmberg=3D
>=C2=A0 =C2=A0 =C2=A0 > 40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@= dmarc.ietf.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >> Hi,
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If what you describe is a technical bug t= hat causes interoperability
>=C2=A0 =C2=A0 =C2=A0 >> problems, then it is within the scope. >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> However, if there is a rogue UAS, the UAC= can simply terminate the session.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Regards,
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Christer
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 >> From: OKUMURA Shinji <ietf.shinji@gmail.com <ma= ilto:ietf.shinji= @gmail.com>>
>=C2=A0 =C2=A0 =C2=A0 >> Sent: perjantai 5. kes=C3=A4kuuta 2020 10= .34
>=C2=A0 =C2=A0 =C2=A0 >> To: sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >> Cc: Christer Holmberg <christer.holmberg@eric= sson.com <mailto:christer.holmberg@ericsson.com>>
>=C2=A0 =C2=A0 =C2=A0 >> Subject: RFC4028 : bug in 11 Security Con= siderations
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Hi,
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> 11.=C2=A0 Security Considerations
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 Next, consider the ca= se of a rogue UAS that wishes to force a UAC to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 generate refreshes at= a rapid rate.=C2=A0 In that case, the UAC has to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 support session timer= .=C2=A0 The initial INVITE arrives at the rogue UAS,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 which returns a 2xx w= ith a very small session interval.=C2=A0 The UAC uses
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 this timer and quickl= y sends a refresh.=C2=A0 Section 7.4 requires that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 the UAC copy the curr= ent session interval into the Session-Expires
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 header field in the r= equest.=C2=A0 This enables the proxies to see the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 current value.=C2=A0 = The proxies will reject this request and provide a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 Min-SE with a higher = minimum, which the UAC will then use.=C2=A0 Note,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 that if the proxies d= id not reject the request, but rather proxied
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 the request with a Mi= n-SE header field, an attack would still be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 possible.=C2=A0 The U= AS could discard this header field in a 2xx response
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 and force the UAC to = continue to generate rapid requests.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If the rogue UAS returns again a 2xx with= a very small session interval,
>=C2=A0 =C2=A0 =C2=A0 >> the attack will continue. To prevent this= case, I think the UAC and proxies
>=C2=A0 =C2=A0 =C2=A0 >> SHOULD make sure that the SE-value and MS= E-value in the response are
>=C2=A0 =C2=A0 =C2=A0 >> greater than or equal to the MSE-value in= a sent request. And ... what
>=C2=A0 =C2=A0 =C2=A0 >> should the UAC and proxies do? Should the= y modify the response?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Is this included in the scope of the bis?=
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Regards,
>=C2=A0 =C2=A0 =C2=A0 >> Shinji
>=C2=A0 =C2=A0 =C2=A0 >> _________________________________________= ______
>=C2=A0 =C2=A0 =C2=A0 >> sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0 >> sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org/= mailman/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >
>
--0000000000004a751105a798c091-- From nobody Mon Jun 8 18:41:09 2020 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 A15243A08EB for ; Mon, 8 Jun 2020 18:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk4L3AqHkL9m for ; Mon, 8 Jun 2020 18:41:07 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 5179C3A08EA for ; Mon, 8 Jun 2020 18:41:07 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id o6so9596946pgh.2 for ; Mon, 08 Jun 2020 18:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=GBvndnOX6a72ASbhgM4sT9iqr0nsNEDt6205cb4KTqw=; b=CX/AGJA8nUx5FkSBqWedmiV/u0j1M1JORu+U3EKN+fbgFddDphC6FzwIN4kPrwE6C/ kdcdv+SrOgDecPJx62KGTkgWgxkzWhiQgsPcSG5D+zkeGG5+7rw9X5xZdGI087Odlucn AqopoTYbu9+BLdN6sZL2BUIphB9ESPmL4ed5ypfcsDhftf3ps7xR7muuuK6CxGHJNCWK IVSND4K4TS8f5NO3OrODDOffNPx/oG3y02inQ4Ydtki+y7qMhw1pCxmoW8fE1UhMLOBp +xaNrxR3/474xyapJ6zoi3OF+zjAvG/c3AF3j0IP48VIvEhsT9eZOHDiHjEPbHkdfaOq rLLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=GBvndnOX6a72ASbhgM4sT9iqr0nsNEDt6205cb4KTqw=; b=FhhtvIBtGsoQCqYAe/HF9Sso/jli8iwhtJ8Q87utG7sl71Q0+48zQkqIR/kLfmUmou FDyAesm3YEP7aZfWsOdxWa4+56WXfnFkEJHFh8znMygu8kdd4+ZowbekIEQCBOXmUTgX 4fEmnbsXA1cS1/ogeEf6+AdfjTlv748Zmsa5ESv1vdkupP8/PaYCLsSSvkNFzE562WXD QKKAEpfSMAnsPdzypWH5r2/bab11MEW7Y1eKUADM/U/ncEtOXu6n5r1lio/lZ1eoT09W yh8FwSrQYppfCYoiyFTVezBh75bGR66mgNAO8H3/fmkv6ZYom5HDXZDv+kjDh0qYtt1w sleQ== X-Gm-Message-State: AOAM532lKcFkS4rjTlX9ja4lEwnLjiaQAm+sN8NdOpqaF50fPXhDJsbY uC+GZYbr0nH2QPRsKkgBkwI= X-Google-Smtp-Source: ABdhPJwapcZra27m3XKv7L0qkMPvMmFL1CtVoEwsQP8FR5DhrPuZN0q3lp+Wm9FIWY4u36QdHyt/2w== X-Received: by 2002:a63:de18:: with SMTP id f24mr21729517pgg.415.1591666866721; Mon, 08 Jun 2020 18:41:06 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id t9sm664594pjs.16.2020.06.08.18.41.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 18:41:06 -0700 (PDT) To: "sipcore@ietf.org" From: OKUMURA Shinji Message-ID: <12989faf-3b59-9ac6-c398-af38bab6e7b6@gmail.com> Date: Tue, 9 Jun 2020 10:41:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : Bug in 8.1. Processing of Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 01:41:09 -0000 Hi, I previously suggested the following. https://github.com/cdh4u/draft-sessiontimer-race/issues/1 Section 8.1 says: ======================================================================== A proxy MUST NOT insert a Min-SE header field or modify the value of an existing header field in a proxied request if that request contains a Supported header field with the value 'timer'. ======================================================================== It should say: ======================================================================== A proxy MAY insert a Min-SE header field or increase the value of an existing header field in a proxied request. But if a request contains a Supported header field with the value 'timer' and Session-Expires header field, the value MUST NOT be greater than the value in the Session-Expires header field. ======================================================================== Regards, Shinji From nobody Mon Jun 8 19:17:43 2020 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 548A73A092D for ; Mon, 8 Jun 2020 19:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3ZfZHSIhNRW for ; Mon, 8 Jun 2020 19:17:39 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 B80533A092C for ; Mon, 8 Jun 2020 19:17:39 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id q24so698067pjd.1 for ; Mon, 08 Jun 2020 19:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LbsNbVQMzAU1GLujKbjRbavOUvHCzIsa+Th2o93iaiQ=; b=YmK+bltQOPZ8qkK3kMahu3qjm0TfUy3APHqHENnlTunwv8BQOAw4mU7oZJ5wATKCeJ VxucC/OCOS5UsRivP4U88Zuy9+wBgLlwXuoZzLR9e6+8ltJ2KmFVLQJUT3eR4Nruo/GT uYo5gbfijcv6D8hnKk0Qe0LIOd0i0YZU+JA0HGk3VxnkKi6eYP9JTKcQh8VnfcTr7Zgk 4hgL/snaIFybYjOw9jJCfsQDnDwWsL5mTxfzJLWtNgUuhaOiAFqcyWlcfbYMPMp85+kt GJdn1g99ANtSosy0KywvHGtHdfrrN6q0tXmhOfnbWDWw9PzKg5WlSa4Lza4yZwGaa5Ni q93w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LbsNbVQMzAU1GLujKbjRbavOUvHCzIsa+Th2o93iaiQ=; b=pW+SplVkN5bwnk0AAkStwMHQaEttvVEx/yH7A9VtGNUKuFuZmiEUrGt8vRERRXKhLZ WRI8qClXRtGy3pplobIJ5IzXBUNimnX1bRPdWxHitRGcIzHDemK1qiy3S14xrwdngLQN njRrvSLCPrxDfpfAehiiLrIKY/aWRdKxUG1gSanTSpja888S8H9mATlCUl2QXfjpCzVi qSyDitD4kkHAvA3flHfkrWIh+NucMvPhxHTS+/7cHQGo3nIKn2mDCIjjMAWEZTtw+7pE zsLqJLGpCYjlwMaEw9lTcNCP0klpz+hAkIaRuhxLokKUNVvUv/eHQUt8ZLVegnpGWrPP uzTw== X-Gm-Message-State: AOAM530VIx5cxUtjPm4QgEFTBNHfG62BeKOcrpUhUo5y6ne18DayMvZT 1bQ2Xqd0wPLNzU3Hy6NrwgX4W3bD X-Google-Smtp-Source: ABdhPJz2I1QFqe0MLzSmAHcSmLRsyM01o4jcGB4cv9Dfw5b6oNNnHPk6ROTXGhGk7pjpP3UGrG/v3g== X-Received: by 2002:a17:902:b092:: with SMTP id p18mr1329077plr.205.1591669059059; Mon, 08 Jun 2020 19:17:39 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 191sm8428905pfy.161.2020.06.08.19.17.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 19:17:38 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Roman Shpount References: Message-ID: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> Date: Tue, 9 Jun 2020 11:17:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 02:17:41 -0000 Roman, This is a clarification. So this does not cause any issues. But I think it's unclear that a Min-SE header in UPDATE is initialized as a result. Do you agree on this point? Regards, Shinji On 2020/06/08 17:05, Roman Shpount wrote: > Shinji, > > This seems like a clarification, not a correction. I think it only should > be addressed if there are known issues caused by this. > _____________ > Roman Shpount > > > On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji wrote: > >> HI, >> >> ======================================================================== >> 7.4. Generating Subsequent Session Refresh Requests >> The value of the Min-SE header field present in a session refresh >> request MUST be the largest value among all Min-SE header field >> values returned in all 422 responses or received in session refresh >> requests, on the same dialog, if a dialog has been established. If >> no dialog has been established, the Min-SE header field value is set >> to the largest value among all Min-SE header field values returned in >> all 422 responses for an INVITE request with the same Call-ID. A >> result of this rule is that the maximum value of the Min-SE is >> effectively 'cleared' once the dialog is established, and from that >> point on, only the values from proxies known to be on the proxy path >> will end up being used. >> ======================================================================== >> >> My interpretation is as shown in the figure below. >> >> Alice Proxy P1 >> |(1) INVITE | >> |SE: 1200 | >> |MSE: 300 | >> |----------->| <-- initial MSE is 300 >> |(2) 422 | >> |MSE: 900 | >> |<-----------| <-- MSE is set to 900 >> |(3) ACK | >> |----------->| >> |(4) INVITE | >> |SE:1200 | >> |MSE:900 | >> |----------->| >> |(5) 200 OK | >> |SE:900 | >> |<-----------| <-- dialog is established and MSE is cleared >> |(6) ACK | >> |----------->| >> |(7) UPDATE | >> |SE:900 | >> |MSE:300 | >> |----------->| <-- MSE is 300 >> >> In order to understand this description clearly, I think it is necessary >> to show concrete examples. And when an early dialog is established, >> another examples is necessary. >> >> Regards, >> Shinji >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From nobody Mon Jun 8 21:29:28 2020 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 40BC73A08C1 for ; Mon, 8 Jun 2020 21:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ySkN49TJfAOo for ; Mon, 8 Jun 2020 21:29:25 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 1E00F3A08BB for ; Mon, 8 Jun 2020 21:29:24 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id e5so15544437ote.11 for ; Mon, 08 Jun 2020 21:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qc5EF952GFZvaENZB18L5pWExFApOG/A+v1Rzq7h/7o=; b=1nAysogImB69/8LUBC5VtyK0kTGLzZN11xIxVPAhcGvr43K0DGMw8CZjiB/LPOg79g lJmJ3QCd1P/GlmpEj8CKOD2266sKQheVob9UQEIZHzclrYchTFUNTHQWKrFb107+tWnE CSEt4qh2XrJADD7ifP7+G67PNK6nqquX27Uc7BMxRtjT/nKGdIvkwjQ9KM8+s2HTQ/HE 8MfLYqdRvLiSHqAUh5X7GHnpE/OJvRa8296DqBZlY9UPnYJ7OoApeYILDmEYh+NsI+TT A4S3QxuKn5vLpXb+8AcGaDQ3FQtmcjBnaMDPqLYsdZCHQCVSuks76dmb+X0+3xDb5JGi yhYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qc5EF952GFZvaENZB18L5pWExFApOG/A+v1Rzq7h/7o=; b=XDWo0rd2QGc+Kavj1NLWQZXnpF1RHe0h+CJFcrEgzr+pECNlkI1F1Em4pRQBUfysFF zop9GYLshVryfW4uY/Pvb0eWz6hBJ6+moBNsxWEQIIsqNuh6MIpPf1iKKb6PEpw5FOU+ CzIC8xDKvh4XgJN1LWwi3TGqeIzvS+KZ0Dajhbt+v3xwPIn175cdBf/T3GQs/fBQ7JUo auR1fZroxz9Mxwjyd0BDaZtTJ7Ed2mhi5nl89qXMFE3rmHcDtN3ZN0cRD0VqQk+NNezI 1oigdBqsRAEUY64BehmoGBw+7mlHHsFPYr0iF2HHWtF7OeNfilJEb03ClnY1qdqy5tlp TicQ== X-Gm-Message-State: AOAM5313RgubtkuXFuwejN7FLgwakiZadecCu3GTz88/4h0bUb3GoTFi eXAULem2wJaAc4t24NSbDNYbauG14FI= X-Google-Smtp-Source: ABdhPJzxNJyHgopvaWwcnOm6IzCu0x1pZ5xvD2gXv4H5+z8cBeDNlxIxaFF4oXFuEEplm5ASvmQ70Q== X-Received: by 2002:a9d:4691:: with SMTP id z17mr17043825ote.88.1591676963727; Mon, 08 Jun 2020 21:29:23 -0700 (PDT) Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com. [209.85.161.47]) by smtp.gmail.com with ESMTPSA id q2sm1928354oti.36.2020.06.08.21.29.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 21:29:22 -0700 (PDT) Received: by mail-oo1-f47.google.com with SMTP id e8so3916836ooi.11 for ; Mon, 08 Jun 2020 21:29:22 -0700 (PDT) X-Received: by 2002:a4a:96f1:: with SMTP id t46mr19694186ooi.75.1591676961937; Mon, 08 Jun 2020 21:29:21 -0700 (PDT) MIME-Version: 1.0 References: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> In-Reply-To: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> From: Roman Shpount Date: Tue, 9 Jun 2020 00:29:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000e9dd1e05a79f2bfa" Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 04:29:27 -0000 --000000000000e9dd1e05a79f2bfa Content-Type: text/plain; charset="UTF-8" Shinji, Each change that you propose, even if it is editorial or a simple clarification, would cause the group to analyse and review the whole affected section as if it was written from scratch. This can result in additional months of work for people writing and reviewing the document. This is why the scope for the current document update was limited to fixing the glare issue and any other issues that are causing current interop issues. Does the thing you have mentioned cause any known interop issues? If it does not, we are not going to touch this. BTW, your example is incorrect. If (1) INVITE had SE set to 1200, it should not get the 422 response with Min-SE 900. Since the value of SE in the INVITE was higher than Min-SE required by proxy, INVITE should have been proxied, and the Min-SE value in the INVITE request increased. _____________ Roman Shpount On Mon, Jun 8, 2020 at 10:17 PM OKUMURA Shinji wrote: > Roman, > > This is a clarification. So this does not cause any issues. > But I think it's unclear that a Min-SE header in UPDATE is initialized as > a result. > Do you agree on this point? > > Regards, > Shinji > > On 2020/06/08 17:05, Roman Shpount wrote: > > Shinji, > > > > This seems like a clarification, not a correction. I think it only should > > be addressed if there are known issues caused by this. > > _____________ > > Roman Shpount > > > > > > On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji > wrote: > > > >> HI, > >> > >> ======================================================================== > >> 7.4. Generating Subsequent Session Refresh Requests > >> The value of the Min-SE header field present in a session refresh > >> request MUST be the largest value among all Min-SE header field > >> values returned in all 422 responses or received in session refresh > >> requests, on the same dialog, if a dialog has been established. If > >> no dialog has been established, the Min-SE header field value is > set > >> to the largest value among all Min-SE header field values returned > in > >> all 422 responses for an INVITE request with the same Call-ID. A > >> result of this rule is that the maximum value of the Min-SE is > >> effectively 'cleared' once the dialog is established, and from that > >> point on, only the values from proxies known to be on the proxy > path > >> will end up being used. > >> ======================================================================== > >> > >> My interpretation is as shown in the figure below. > >> > >> Alice Proxy P1 > >> |(1) INVITE | > >> |SE: 1200 | > >> |MSE: 300 | > >> |----------->| <-- initial MSE is 300 > >> |(2) 422 | > >> |MSE: 900 | > >> |<-----------| <-- MSE is set to 900 > >> |(3) ACK | > >> |----------->| > >> |(4) INVITE | > >> |SE:1200 | > >> |MSE:900 | > >> |----------->| > >> |(5) 200 OK | > >> |SE:900 | > >> |<-----------| <-- dialog is established and MSE is cleared > >> |(6) ACK | > >> |----------->| > >> |(7) UPDATE | > >> |SE:900 | > >> |MSE:300 | > >> |----------->| <-- MSE is 300 > >> > >> In order to understand this description clearly, I think it is necessary > >> to show concrete examples. And when an early dialog is established, > >> another examples is necessary. > >> > >> Regards, > >> Shinji > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > --000000000000e9dd1e05a79f2bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

Each change that you propose, e= ven if it is editorial or a simple clarification,=C2=A0would cause the grou= p to analyse and=C2=A0review the whole affected section as if it was writte= n from scratch. This can result in additional months of work for people wri= ting and reviewing the document. This is why the scope for the current docu= ment update=C2=A0was limited to fixing the glare issue and any other issues= that are causing current interop issues.

Does the= thing you have mentioned=C2=A0cause any known interop issues? If it does n= ot, we are not going to touch this.

BTW, your exam= ple=C2=A0is incorrect. If=20 (1) INVITE=C2=A0 had SE set to=C2=A01200, it s= hould not get the 422 response with Min-SE 900. Since the value of SE in th= e INVITE was higher than Min-SE required by proxy, INVITE should have been = proxied, and the Min-SE value in the INVITE request increased.
_____________
Roman Shpount


On= Mon, Jun 8, 2020 at 10:17 PM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
Roman,

This is a clarification. So this does not cause any issues.
But I think it's unclear that a Min-SE header in UPDATE is initialized = as a result.
Do you agree on this point?

Regards,
Shinji

On 2020/06/08 17:05, Roman Shpount wrote:
> Shinji,
>
> This seems like a clarification, not a correction. I think it only sho= uld
> be addressed if there are known issues caused by this.
> _____________
> Roman Shpount
>
>
> On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:=
>
>> HI,
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> 7.4.=C2=A0 Generating Subsequent Session Refresh Requests
>>=C2=A0 =C2=A0 =C2=A0 The value of the Min-SE header field present i= n a session refresh
>>=C2=A0 =C2=A0 =C2=A0 request MUST be the largest value among all Mi= n-SE header field
>>=C2=A0 =C2=A0 =C2=A0 values returned in all 422 responses or receiv= ed in session refresh
>>=C2=A0 =C2=A0 =C2=A0 requests, on the same dialog, if a dialog has = been established.=C2=A0 If
>>=C2=A0 =C2=A0 =C2=A0 no dialog has been established, the Min-SE hea= der field value is set
>>=C2=A0 =C2=A0 =C2=A0 to the largest value among all Min-SE header f= ield values returned in
>>=C2=A0 =C2=A0 =C2=A0 all 422 responses for an INVITE request with t= he same Call-ID.=C2=A0 A
>>=C2=A0 =C2=A0 =C2=A0 result of this rule is that the maximum value = of the Min-SE is
>>=C2=A0 =C2=A0 =C2=A0 effectively 'cleared' once the dialog = is established, and from that
>>=C2=A0 =C2=A0 =C2=A0 point on, only the values from proxies known t= o be on the proxy path
>>=C2=A0 =C2=A0 =C2=A0 will end up being used.
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>
>> My interpretation is as shown in the figure below.
>>
>>=C2=A0 =C2=A0 =C2=A0 Alice=C2=A0 =C2=A0 =C2=A0 Proxy P1
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(1) INVITE=C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |SE: 1200=C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |MSE: 300=C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------->|=C2=A0 =C2=A0<-- in= itial MSE is 300
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(2) 422=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |MSE: 900=C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-----------|=C2=A0 =C2=A0<-- MS= E is set to 900
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(3) ACK=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------->|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(4) INVITE=C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |SE:1200=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |MSE:900=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------->|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(5) 200 OK=C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |SE:900=C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-----------|=C2=A0 =C2=A0<-- di= alog is established and MSE is cleared
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(6) ACK=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------->|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |(7) UPDATE=C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |SE:900=C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |MSE:300=C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |----------->|=C2=A0 =C2=A0<-- MS= E is 300
>>
>> In order to understand this description clearly, I think it is nec= essary
>> to show concrete examples. And when an early dialog is established= ,
>> another examples is necessary.
>>
>> Regards,
>> Shinji
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>
--000000000000e9dd1e05a79f2bfa-- From nobody Mon Jun 8 22:59:46 2020 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 641563A096D for ; Mon, 8 Jun 2020 22:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhuWGeOtV2uT for ; Mon, 8 Jun 2020 22:59:42 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 835073A07BB for ; Mon, 8 Jun 2020 22:59:42 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id z64so9612702pfb.1 for ; Mon, 08 Jun 2020 22:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sz+c4hs+QjY5Q7FCQaJ5H1vWkDw5HTpZD4MLLoHnKOw=; b=boCvXZtZayO8tyqiB5waO9+/Q9Q+11ITOnskJcXwdvD5L3WBi00VMA2wkNO27CoFX7 7uj8t+QDgohfLp/rgIQ/3xI/lgl3Sq5S1wkVXHkD7aJ4UlwI/Ivf9TQjrq1iNaVxSehv VnVB30YdCAgB+njV7tlcycqnZyd2TT+r/50aKTuTTxLaiQVlJKORH2aapOKcY4o4xFFb MvHpbLwftUNUdz+hbpNxbK1W+9houfS0FEJCs+0ISMHsBRbrqv1YV7ysryiPhCk+eXW1 6XjC2G/x7UZisTZEdigfpZVquw71IYOTg2/NcG8v6BDIdsg2ORjqq0t4qL2SHgeHUhQ5 gDpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sz+c4hs+QjY5Q7FCQaJ5H1vWkDw5HTpZD4MLLoHnKOw=; b=LSmE0GVGIjaKTfM2ELnSgSJdkmyuw8nFI90Hq3Sau0bKdpbWm2dPEKs11RngXrpop9 Ko7cG9J1N1A0exWUTazm48q/8y2pErkBOKFpXCGD2RxdvHWwVBDiGzF5tKAQn2hwQqCr 0S67ntw2kzP7FBcORh4pRUR0utFl58UM3OYP1FIQ0MRNhAHpLGI2lPD5/63Ce6t3neh5 R6gvbyhFgvT8Z2IR1q2ucu2u4Jur2HFiAIwpJ+7EKoS/Lw4owmHC7ZyZyP5vkKIEVR8i QuZGIs4mqoaDIinvAMuUJew9E5IhOJmTBZxZ642RlfBxY8JppEKiSM2x3rJz5xFXmNKU lfBg== X-Gm-Message-State: AOAM531+KM8u0BpsRbmR71XhAEnRZoCAmQyVbGRYUld0cUwiVklDzW9O A1VRzTMa3BFcPUd5oI6DXVM= X-Google-Smtp-Source: ABdhPJzdt37L9bDeRPZ1kSrfQwa+ZBiAIKRpV40gNKEbSUH6zhsFwO7D2i+kO3TDGi36U32UcTOODw== X-Received: by 2002:a63:fc5c:: with SMTP id r28mr1997619pgk.96.1591682381129; Mon, 08 Jun 2020 22:59:41 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id a11sm5114384pff.39.2020.06.08.22.59.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 22:59:40 -0700 (PDT) To: Roman Shpount Cc: "sipcore@ietf.org" , Christer Holmberg References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> From: OKUMURA Shinji Message-ID: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> Date: Tue, 9 Jun 2020 14:59:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 05:59:44 -0000 Roman, This issue occurs really when current RFC-compliant UAC and proxies encounter such UAS. I don't know why you don't think this is a problem. And I don't like the policy that we don't have to do anything, as a good proxy will solve all the issues. Regards, Shinji On 2020/06/09 5:49, Roman Shpount wrote: > Shinji, > > Yes, only proxy is going to notice the problem, but since proxy needs to deal with denial of service attacks anyway, it will deal with clients that set Session-Timer to a value which is too small. > > My view is that Min-SE is advisory. UA can disregard both Min-SE and Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy would need to gracefully deal with it. We can update security considerations to mention this, but once again, unless this is causing known interop issues, I would prefer not to touch this. > > Best Regards, > _____________ > Roman Shpount > > > On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji > wrote: > > Hi, > > Sometimes only a proxy can notice the problem. If the value returned by a UAS is fine for the UAC, the UAC does not notice the problem. > > Regards, > Shinji > > On 2020/06/08 17:19, Roman Shpount wrote: > > Shinji, > > > > My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji >> wrote: > > > >     Hi, > > > >     A 200 response has no Min-SE header. > > > >     My suggestion is below. > > > >     In this case, the UAC and proxies should follow the procedures defined > >     in section 7.2 and 8.2 as if the Session-Expires header field were not > >     in the 2xx response. > > > >     Regards, > >     Shinji > > > >     On 2020/06/05 18:35, Roman Shpount wrote: > >      > Proxy, if it receives a 2xx response with Min-SE header set to a value > >      > lower then Min-SE set by the proxy in the corresponding request, should > >      > increase Min-SE to the desired proxy value. > >      > > >      > UAC, if it receives a 2xx response with Session-Expires set to a value > >      > below Min-SE in the response or original request from the UAC. should > >      > immediately terminate a call. > >      > > >      > Unfortunately, proxy has no graceful way to terminate a call, so if both > >      > UAC and UAS are rogue, this will result in frequent session refresh > >      > transactions. > >      > > >      > In practice, this is not an issue, since proxy, when communicating with > >      > untrusted end points, typically have a some sort of dynamic rate limiter to > >      > prevent denial of service attacks such as opensips PIKE module ( > >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to > >      > efficiently drop SIP message from badly behaving clients. > >      > > >      > Best Regards, > >      > _____________ > >      > Roman Shpount > >      > > >      > > >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg >      > 40ericsson.com@dmarc.ietf.org >> wrote: > >      > > >      >> Hi, > >      >> > >      >> If what you describe is a technical bug that causes interoperability > >      >> problems, then it is within the scope. > >      >> > >      >> However, if there is a rogue UAS, the UAC can simply terminate the session. > >      >> > >      >> Regards, > >      >> > >      >> Christer > >      >> > >      >> > >      >> > >      >> -----Original Message----- > >      >> From: OKUMURA Shinji >> > >      >> Sent: perjantai 5. kesäkuuta 2020 10.34 > >      >> To: sipcore@ietf.org > > >      >> Cc: Christer Holmberg >> > >      >> Subject: RFC4028 : bug in 11 Security Considerations > >      >> > >      >> Hi, > >      >> > >      >> 11.  Security Considerations > >      >>      Next, consider the case of a rogue UAS that wishes to force a UAC to > >      >>      generate refreshes at a rapid rate.  In that case, the UAC has to > >      >>      support session timer.  The initial INVITE arrives at the rogue UAS, > >      >>      which returns a 2xx with a very small session interval.  The UAC uses > >      >>      this timer and quickly sends a refresh.  Section 7.4 requires that > >      >>      the UAC copy the current session interval into the Session-Expires > >      >>      header field in the request.  This enables the proxies to see the > >      >>      current value.  The proxies will reject this request and provide a > >      >>      Min-SE with a higher minimum, which the UAC will then use.  Note, > >      >>      that if the proxies did not reject the request, but rather proxied > >      >>      the request with a Min-SE header field, an attack would still be > >      >>      possible.  The UAS could discard this header field in a 2xx response > >      >>      and force the UAC to continue to generate rapid requests. > >      >> > >      >> If the rogue UAS returns again a 2xx with a very small session interval, > >      >> the attack will continue. To prevent this case, I think the UAC and proxies > >      >> SHOULD make sure that the SE-value and MSE-value in the response are > >      >> greater than or equal to the MSE-value in a sent request. And ... what > >      >> should the UAC and proxies do? Should they modify the response? > >      >> > >      >> Is this included in the scope of the bis? > >      >> > >      >> Regards, > >      >> Shinji > >      >> _______________________________________________ > >      >> sipcore mailing list > >      >> sipcore@ietf.org > > >      >> https://www.ietf.org/mailman/listinfo/sipcore > >      >> > >      > > > > From nobody Mon Jun 8 23:11:30 2020 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 BB4343A09A2 for ; Mon, 8 Jun 2020 23:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqjkMu3Ro3ZR for ; Mon, 8 Jun 2020 23:11:26 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 B29483A09A0 for ; Mon, 8 Jun 2020 23:11:26 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id bh7so7608515plb.11 for ; Mon, 08 Jun 2020 23:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1LuUz0kEQV5YGTWYtkO4u0rQZATDSzw6XIu4T6KzN3M=; b=WeAiNr0+fv/upVRsn6A8qRgGRIEAo0wTwAowgwj8KyNpMFGZaKIsZydm7mv1K4Zl/M WRccnDNNSkDaqM7qwsFMggyBENU8VzsSCS9UKxO9F30KjVIcmfQtiMs7SKm6h4+TnGTA JL2DgD2xV50NLO64UlZ2gBGC7IoYVRvEPa8Jb3ySsVJzFLEKxoa1qKrEgXmGQmDq4/9N K/sskUopZ+zrYrw/CXWdhctTPrxozmMD6/SFJp42POBvyD46zPvSalX6G16p9Dwn/EbO D4gZETOVS/VfwwWplhfK/QPwtThieOAZJPlTmFtHLYrP7LbXwo5eihyvg/j+uVGtjsoM 7vMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1LuUz0kEQV5YGTWYtkO4u0rQZATDSzw6XIu4T6KzN3M=; b=nv+lXSz6h+vw4PHdpdbMwVM7iwIDrvJ+p59s0GeqqlGDATeoz/klF2RqUsQYAtHyZv nUjAJpZDOWyngSUEqjOnm3c6J1JsBN4wPN+mYO0depg1ahJy+OciG6E//q9nrJlvIC/t adowCNKwlFponIMi+pEjVnDW1mXQKC49+J1KHrTUiyvZEhwwaNDfWC3gpVqjzHZRjYhk s39aLfU5EnDq22VjpkC31Vh62x64ab+A9wuJSPdYmi3nX7mTuZRvnTiPQdYfviSApu7G wo1owEpfUXn2sTbIxTI18AcbCUUitZjCus8M7FtjYzajcw93vRZQXd/WK7YMuhXPbNt4 E4Cg== X-Gm-Message-State: AOAM533UaG8H5GV7TC+22STang2XapmAQWXr4ynzcdgUd0IdlD65y1Xg 0BPSlHBWeqVPJFlnoaz4n1PDCbc6 X-Google-Smtp-Source: ABdhPJzxeNxF/eIatj4ujh0PuCzlhf/8A9xzOMPu1k3Yvhhy1OA6mMywUzOn9lCvHyOf01t424zblA== X-Received: by 2002:a17:90a:36cf:: with SMTP id t73mr3151210pjb.100.1591683085679; Mon, 08 Jun 2020 23:11:25 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 17sm8899965pfn.19.2020.06.08.23.11.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 23:11:24 -0700 (PDT) To: Roman Shpount Cc: SIPCORE References: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> From: OKUMURA Shinji Message-ID: <7e27adb7-08b3-9467-f637-fd4cc2e05c68@gmail.com> Date: Tue, 9 Jun 2020 15:11:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 06:11:29 -0000 Roman, I think my suggestions are not just editorial or a simple clarification. I'm saying that current RFC4028 causes any interop issues. The session-timer glare is the main scope, I see. I see also a new invention is out of scope, but Errata, bug-fix and clarification are in the scope. 4028bis does not only update RFC4028, but obsoletes it. Also, I don't think a full revision is necessary. If necessary, I will write it. For my example, there are other proxies omitted from the diagram. P1 reduces SE to 300. P2 rejects by 422. Regards, Shinji On 2020/06/09 13:29, Roman Shpount wrote: > Shinji, > > Each change that you propose, even if it is editorial or a simple clarification, would cause the group to analyse and review the whole affected section as if it was written from scratch. This can result in additional months of work for people writing and reviewing the document. This is why the scope for the current document update was limited to fixing the glare issue and any other issues that are causing current interop issues. > > Does the thing you have mentioned cause any known interop issues? If it does not, we are not going to touch this. > > BTW, your example is incorrect. If (1) INVITE  had SE set to 1200, it should not get the 422 response with Min-SE 900. Since the value of SE in the INVITE was higher than Min-SE required by proxy, INVITE should have been proxied, and the Min-SE value in the INVITE request increased. > _____________ > Roman Shpount > > > On Mon, Jun 8, 2020 at 10:17 PM OKUMURA Shinji > wrote: > > Roman, > > This is a clarification. So this does not cause any issues. > But I think it's unclear that a Min-SE header in UPDATE is initialized as a result. > Do you agree on this point? > > Regards, > Shinji > > On 2020/06/08 17:05, Roman Shpount wrote: > > Shinji, > > > > This seems like a clarification, not a correction. I think it only should > > be addressed if there are known issues caused by this. > > _____________ > > Roman Shpount > > > > > > On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji > wrote: > > > >> HI, > >> > >> ======================================================================== > >> 7.4.  Generating Subsequent Session Refresh Requests > >>      The value of the Min-SE header field present in a session refresh > >>      request MUST be the largest value among all Min-SE header field > >>      values returned in all 422 responses or received in session refresh > >>      requests, on the same dialog, if a dialog has been established.  If > >>      no dialog has been established, the Min-SE header field value is set > >>      to the largest value among all Min-SE header field values returned in > >>      all 422 responses for an INVITE request with the same Call-ID.  A > >>      result of this rule is that the maximum value of the Min-SE is > >>      effectively 'cleared' once the dialog is established, and from that > >>      point on, only the values from proxies known to be on the proxy path > >>      will end up being used. > >> ======================================================================== > >> > >> My interpretation is as shown in the figure below. > >> > >>      Alice      Proxy P1 > >>        |(1) INVITE  | > >>        |SE: 1200    | > >>        |MSE: 300    | > >>        |----------->|   <-- initial MSE is 300 > >>        |(2) 422     | > >>        |MSE: 900    | > >>        |<-----------|   <-- MSE is set to 900 > >>        |(3) ACK     | > >>        |----------->| > >>        |(4) INVITE  | > >>        |SE:1200     | > >>        |MSE:900     | > >>        |----------->| > >>        |(5) 200 OK  | > >>        |SE:900      | > >>        |<-----------|   <-- dialog is established and MSE is cleared > >>        |(6) ACK     | > >>        |----------->| > >>        |(7) UPDATE  | > >>        |SE:900      | > >>        |MSE:300     | > >>        |----------->|   <-- MSE is 300 > >> > >> In order to understand this description clearly, I think it is necessary > >> to show concrete examples. And when an early dialog is established, > >> another examples is necessary. > >> > >> Regards, > >> Shinji > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > From nobody Mon Jun 8 23:37:57 2020 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 14BDD3A09F1 for ; Mon, 8 Jun 2020 23:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 mlB3R4b9j_7B for ; Mon, 8 Jun 2020 23:37:53 -0700 (PDT) Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 BB1983A09BE for ; Mon, 8 Jun 2020 23:37:53 -0700 (PDT) Received: by mail-oo1-xc2f.google.com with SMTP id q188so3967924ooq.4 for ; Mon, 08 Jun 2020 23:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O++F+gQBqLVkNmydk3pPDJ1ASuSARnuaRJul1zPE6uc=; b=W6X/d1RIczWbnFxJP9x5lbIjQmq3lHRxwvswuCZHVd6QjOvhqpc6T06FTZ7bsiJ6W7 8H7/sUCrm2/C9Mz/QLiEZPakOcWiz1CTY/vmiTeYawkYcfvrLipnTgcCiZMWYFzPOMBM HCx/EyeOmkTdCexqU/seT1N5RO4CTA99IXxKAF1jFqO9NDrSoooDAH23ONJYqFl4O/Rt 0EWj/dAW2rORGhZcZ4iipqV4gaiLwwyuEFh7VO+l2AUuMEOmHVepEMkW3OyzP9vWEuDl nixZFweEwFujKJ3Sd4UO58igoAcMNnt7mjQjj7TPy2KZkiYmBW0I6fKF6QsNNI6n3B37 qLnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O++F+gQBqLVkNmydk3pPDJ1ASuSARnuaRJul1zPE6uc=; b=LfhZBQAmaPt6fxsQNYBQ4D6xvTpp6PUZNgxPPm04jdJ41+BCvr16PPeb09Ivec1h+T fRT1/2nm2C42xxRgQQPKOfI2zrBfE20ZxEz8PW4lWnfnqylgab6dZfnYzT89uJ8nNsoa Y79KvH7HV3m3VseJ9x0lZQwLCop1VGWKN7IYrQQui09w9o0r5Dt/qxeRiQ5EV3siQCLy eTowAQgSN6e/WjeNFL8BaCAlPhEp3OUk5f2UVfWS0gRBAy18kD6qZgK3w1/ud4B/Hqtg SoN+JwCj5Mucxz4tK8zy/nM119fizsI3/qyqrnAnixWmTY5dLqceifmRXjKFDCoOAGMp zyAg== X-Gm-Message-State: AOAM530tv+OFVHlpyIBauohiJritQ/kaw/y19xolFNlfmrH0AGu9lNT3 z/BGHdBap6iz5NK3FXtIxPL0JpspYPo= X-Google-Smtp-Source: ABdhPJw9FYT6JvMo4PGbJyp97tvsEXsHs6VnsY71Tn/7O1j4dqJA9G3XH4MDz6x7yo7V/YpyFvWEQQ== X-Received: by 2002:a4a:3811:: with SMTP id c17mr19709713ooa.91.1591684671515; Mon, 08 Jun 2020 23:37:51 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id d15sm2035505otk.41.2020.06.08.23.37.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 23:37:50 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id 69so15753285otv.2 for ; Mon, 08 Jun 2020 23:37:50 -0700 (PDT) X-Received: by 2002:a05:6830:1d1:: with SMTP id r17mr10766980ota.19.1591684669771; Mon, 08 Jun 2020 23:37:49 -0700 (PDT) MIME-Version: 1.0 References: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> <7e27adb7-08b3-9467-f637-fd4cc2e05c68@gmail.com> In-Reply-To: <7e27adb7-08b3-9467-f637-fd4cc2e05c68@gmail.com> From: Roman Shpount Date: Tue, 9 Jun 2020 02:37:38 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000056166005a7a0f740" Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 06:37:55 -0000 --00000000000056166005a7a0f740 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 9, 2020 at 2:11 AM OKUMURA Shinji wrote: > The session-timer glare is the main scope, I see. I see also a new > invention is out of scope, but Errata, bug-fix and clarification are in the > scope. 4028bis does not only update RFC4028, but obsoletes it. Also, I > don't think a full revision is necessary. If necessary, I will write it. > I think clarifications are in-scope and they address real issues in the field. > For my example, there are other proxies omitted from the diagram. > P1 reduces SE to 300. > P2 rejects by 422. > > I see. This is interesting since this will cause subsequent UPDATE to be refused with 422 by the proxy P2 and then resent by UAC with higher Min-SE and lower SE value. Do you see this happening in practice? Thank You, _____________ Roman Shpount --00000000000056166005a7a0f740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The session-timer glare is the main scope, I see. I = see also a new invention is out of scope, but Errata, bug-fix and clarifica= tion are in the scope. 4028bis does not only update RFC4028, but obsoletes = it. Also, I don't think a full revision is necessary. If necessary, I w= ill write it.

I think clarifications ar= e in-scope and they address real issues in the field.
=C2=A0
For my example, there ar= e other proxies omitted from the diagram.
P1 reduces SE to 300.
P2 rejects by 422.


I see. This is i= nteresting since this will cause subsequent UPDATE=C2=A0to=C2=A0be refused = with 422 by the proxy P2 and then resent=C2=A0 by UAC with higher Min-SE an= d lower SE value.

Do you see this happening in pra= ctice?

Thank You,=C2=A0
_____________
Roman Shpount
<= /div>
--00000000000056166005a7a0f740-- From nobody Mon Jun 8 23:45:43 2020 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 4CFB63A09FB for ; Mon, 8 Jun 2020 23:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IzT9ou7yiC31 for ; Mon, 8 Jun 2020 23:45:40 -0700 (PDT) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 2ED833A09F0 for ; Mon, 8 Jun 2020 23:45:40 -0700 (PDT) Received: by mail-oo1-xc36.google.com with SMTP id v1so3979610ooh.0 for ; Mon, 08 Jun 2020 23:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZY67NXpE1u7thg8u78HQZIA8yxl7g8/v/UX47dmsklg=; b=r6aYlOp+QR/VRrMNUHpARL9lzzCTlHg/pof1KMmrhqODABdZQYPilzyDxlvxXDEZLU WNSSTTH7NNkBYlCcPgKp04HBguLp1VZfvDMkfZan+gpWK9CO6ZYqlcub7OB/B478S6YH CiiGPgZwkayMqiNpIchsz1+C67YJBA7CW0lozRxz9PITMGNbBBVtYr7kGDPEyFeEvIFz XBXVeBqN2HlC9dudaq9BqwaBnKtDtqPJxzryX721Ybcyn0GDSDSXlpbHhr6sMGBTW6sZ LMkK7r/WZ2ZkLyjppPBxsw2kzUlCV0PuJVFF02qPhrsGAM2DOguMOJyvbnB61gUMVFaC rDXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZY67NXpE1u7thg8u78HQZIA8yxl7g8/v/UX47dmsklg=; b=GcpiM/5OV95Oq3uoILO39vnKCvKFUi8uGkLkS7gq4RcVi++r5DdIYC+OomvFDiXf1v IHcuoQDlULpDPq02OmI0yP6sBb/RBVK1Ir5HsCqUSmNvN5a791nhYRw3M3kL3GhFb/7z nEIEJNQhGRYXrvNAduWw8uJUOhSFHivXFIJ/E5N2zIA+jFAZjpUWqj541QET30pD51oO lhBFdmPn0zktu0O91Sfe0+XaINKGhkGj8uJ4cgZ7U55h8BvyeM4WZ4q5NoUJtYNjqgmi b4oZuB/H1CllSR7QVArdtm2Zl1Hv30Zwck86nbGj5W6vXKuRZIvZmaXtqXFN1NEI0EEO 1wDA== X-Gm-Message-State: AOAM531/QR4KIWR5303zTVMir3uaTeZ1LlEZ+i+OTEs1d/JBBr8+Dxm2 tui8eXir27yjqj88jzv1jRtIS9zCuXQ= X-Google-Smtp-Source: ABdhPJyDAwiWUaCPedSgHqOyj6KDFmEkvf9bPJ/LsEg7xdPMDx+Y/Z4bV+8zUfaYUmTg20gLljEoYg== X-Received: by 2002:a4a:e2c1:: with SMTP id l1mr20232011oot.12.1591685138041; Mon, 08 Jun 2020 23:45:38 -0700 (PDT) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com. [209.85.161.49]) by smtp.gmail.com with ESMTPSA id z9sm2032868otk.74.2020.06.08.23.45.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 23:45:37 -0700 (PDT) Received: by mail-oo1-f49.google.com with SMTP id v3so3980578oot.1 for ; Mon, 08 Jun 2020 23:45:36 -0700 (PDT) X-Received: by 2002:a4a:96f1:: with SMTP id t46mr19963404ooi.75.1591685136300; Mon, 08 Jun 2020 23:45:36 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> In-Reply-To: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> From: Roman Shpount Date: Tue, 9 Jun 2020 02:45:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000024c1f105a7a11365" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 06:45:42 -0000 --00000000000024c1f105a7a11365 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Shinji I am saying this issue is not a real issue since it should not affect any real deployments. Do you see this causing problems anywhere? Your solution, on the other hand, is potentially problematic since it will cause a call to connect and then drop due to session timer expiration. I would prefer normative behavior would not change unless someone is actually affected by this. Any proxy which deals with untrusted UA should already deal with this problem using denial of service protection. UAC should disconnect the call if Session-Expires is less then it is willing to support. _____________ Roman Shpount On Tue, Jun 9, 2020 at 1:59 AM OKUMURA Shinji wrote= : > Roman, > > This issue occurs really when current RFC-compliant UAC and proxies > encounter such UAS. I don't know why you don't think this is a problem. A= nd > I don't like the policy that we don't have to do anything, as a good prox= y > will solve all the issues. > > Regards, > Shinji > > On 2020/06/09 5:49, Roman Shpount wrote: > > Shinji, > > > > Yes, only proxy is going to notice the problem, but since proxy needs t= o > deal with denial of service attacks anyway, it will deal with clients tha= t > set Session-Timer to a value which is too small. > > > > My view is that Min-SE is advisory. UA can disregard both Min-SE and > Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy > would need to gracefully deal with it. We can update security > considerations to mention this, but once again, unless this is causing > known interop issues, I would prefer not to touch this. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji > wrote: > > > > Hi, > > > > Sometimes only a proxy can notice the problem. If the value returne= d > by a UAS is fine for the UAC, the UAC does not notice the problem. > > > > Regards, > > Shinji > > > > On 2020/06/08 17:19, Roman Shpount wrote: > > > Shinji, > > > > > > My instinct would be to allow Session-Expires header to pass > through even if it is below Min-SE value, and then let either UAC > disconnect the call or denial of service filter do its job and drop the > session if it starts sending too many requests. > > > > > > Best Regards, > > > _____________ > > > Roman Shpount > > > > > > > > > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji < > ietf.shinji@gmail.com ietf.shinji@gmail.com >> wrote: > > > > > > Hi, > > > > > > A 200 response has no Min-SE header. > > > > > > My suggestion is below. > > > > > > In this case, the UAC and proxies should follow the > procedures defined > > > in section 7.2 and 8.2 as if the Session-Expires header fiel= d > were not > > > in the 2xx response. > > > > > > Regards, > > > Shinji > > > > > > On 2020/06/05 18:35, Roman Shpount wrote: > > > > Proxy, if it receives a 2xx response with Min-SE header > set to a value > > > > lower then Min-SE set by the proxy in the corresponding > request, should > > > > increase Min-SE to the desired proxy value. > > > > > > > > UAC, if it receives a 2xx response with Session-Expires > set to a value > > > > below Min-SE in the response or original request from the > UAC. should > > > > immediately terminate a call. > > > > > > > > Unfortunately, proxy has no graceful way to terminate a > call, so if both > > > > UAC and UAS are rogue, this will result in frequent > session refresh > > > > transactions. > > > > > > > > In practice, this is not an issue, since proxy, when > communicating with > > > > untrusted end points, typically have a some sort of > dynamic rate limiter to > > > > prevent denial of service attacks such as opensips PIKE > module ( > > > > https://opensips.org/docs/modules/3.1.x/pike.html ) , > which are used to > > > > efficiently drop SIP message from badly behaving clients. > > > > > > > > Best Regards, > > > > _____________ > > > > Roman Shpount > > > > > > > > > > > > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg > > > > 40ericsson.com@dmarc.ietf.org 40ericsson.com@dmarc.ietf.org> >> wrote: > > > > > > > >> Hi, > > > >> > > > >> If what you describe is a technical bug that causes > interoperability > > > >> problems, then it is within the scope. > > > >> > > > >> However, if there is a rogue UAS, the UAC can simply > terminate the session. > > > >> > > > >> Regards, > > > >> > > > >> Christer > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: OKUMURA Shinji ietf.shinji@gmail.com> ietf.shinji@gmail.com>>> > > > >> Sent: perjantai 5. kes=C3=A4kuuta 2020 10.34 > > > >> To: sipcore@ietf.org sipcore@ietf.org > > > > >> Cc: Christer Holmberg christer.holmberg@ericsson.com >> > > > >> Subject: RFC4028 : bug in 11 Security Considerations > > > >> > > > >> Hi, > > > >> > > > >> 11. Security Considerations > > > >> Next, consider the case of a rogue UAS that wishes > to force a UAC to > > > >> generate refreshes at a rapid rate. In that case, > the UAC has to > > > >> support session timer. The initial INVITE arrives > at the rogue UAS, > > > >> which returns a 2xx with a very small session > interval. The UAC uses > > > >> this timer and quickly sends a refresh. Section 7.= 4 > requires that > > > >> the UAC copy the current session interval into the > Session-Expires > > > >> header field in the request. This enables the > proxies to see the > > > >> current value. The proxies will reject this reques= t > and provide a > > > >> Min-SE with a higher minimum, which the UAC will > then use. Note, > > > >> that if the proxies did not reject the request, but > rather proxied > > > >> the request with a Min-SE header field, an attack > would still be > > > >> possible. The UAS could discard this header field > in a 2xx response > > > >> and force the UAC to continue to generate rapid > requests. > > > >> > > > >> If the rogue UAS returns again a 2xx with a very small > session interval, > > > >> the attack will continue. To prevent this case, I think > the UAC and proxies > > > >> SHOULD make sure that the SE-value and MSE-value in the > response are > > > >> greater than or equal to the MSE-value in a sent request= . > And ... what > > > >> should the UAC and proxies do? Should they modify the > response? > > > >> > > > >> Is this included in the scope of the bis? > > > >> > > > >> Regards, > > > >> Shinji > > > >> _______________________________________________ > > > >> sipcore mailing list > > > >> sipcore@ietf.org sipcore@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/sipcore > > > >> > > > > > > > > > > --00000000000024c1f105a7a11365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji=C2=A0=C2=A0
=

I am saying this issue is not a real issue since it should=C2=A0not aff= ect any real=C2=A0deployments. Do you see this causing problems anywhere?

<= /div>
Your= solution, on the other hand, is potentially problematic since it will caus= e a call to connect and then drop due to session timer expiration. I would = prefer normative behavior would not change unless someone is actually affec= ted by this. Any proxy which deals with untrusted=C2=A0UA should already de= al with this problem using denial of service protection. UAC should disconn= ect the call if Session-Expires is less then it is willing to support.
_____________
Roman Shpount


On Tue, Jun 9, 2020 at 1:= 59 AM OKUMURA Shinji <ietf.shin= ji@gmail.com> wrote:
Roman,

This issue occurs really when current RFC-compliant UAC and proxies encount= er such UAS. I don't know why you don't think this is a problem. An= d I don't like the policy that we don't have to do anything, as a g= ood proxy will solve all the issues.

Regards,
Shinji

On 2020/06/09 5:49, Roman Shpount wrote:
> Shinji,
>
> Yes, only proxy is going to notice the problem, but since proxy needs = to deal with denial of service attacks anyway, it will deal with clients th= at set Session-Timer to a value which is too small.
>
> My view is that Min-SE is advisory. UA can disregard both Min-SE and S= ession-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy wou= ld need to gracefully deal with it. We can update security considerations t= o mention this, but once again, unless this is causing known interop issues= , I would prefer not to touch this.
>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji <ietf.shinji@gmail.com <mailto= :ietf.shinji@gma= il.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0Sometimes only a proxy can notice the problem. If t= he value returned by a UAS is fine for the UAC, the UAC does not notice the= problem.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Shinji
>
>=C2=A0 =C2=A0 =C2=A0On 2020/06/08 17:19, Roman Shpount wrote:
>=C2=A0 =C2=A0 =C2=A0 > Shinji,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > My instinct=C2=A0would be to allow Session-Ex= pires header to pass through even if it is below Min-SE value, and then let= either UAC disconnect the call or denial of service filter do its job and = drop the session if it starts sending too many requests.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Best Regards,
>=C2=A0 =C2=A0 =C2=A0 > _____________
>=C2=A0 =C2=A0 =C2=A0 > Roman Shpount
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji= <ietf.shinji= @gmail.com <mailto:ietf.shinji@gmail.com> <mailto:ietf.shinji@gmail.com <mailto:<= a href=3D"mailto:ietf.shinji@gmail.com" target=3D"_blank">ietf.shinji@gmail= .com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hi,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A 200 response has no Min-= SE header.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0My suggestion is below. >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0In this case, the UAC and = proxies should follow the procedures defined
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0in section 7.2 and 8.2 as = if the Session-Expires header field were not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0in the 2xx response.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Shinji
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 2020/06/05 18:35, Roman= Shpount wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Proxy, if it receive= s a 2xx response with Min-SE header set to a value
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > lower then Min-SE se= t by the proxy in the corresponding request, should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > increase Min-SE to t= he desired proxy value.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > UAC, if it receives = a 2xx response with Session-Expires set to a value
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > below Min-SE in the = response or original request from the UAC. should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > immediately terminat= e a call.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Unfortunately, proxy= has no graceful way to terminate a call, so if both
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > UAC and UAS are rogu= e, this will result in frequent session refresh
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > transactions.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > In practice, this is= not an issue, since proxy, when communicating with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > untrusted end points= , typically have a some sort of dynamic rate limiter to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > prevent denial of se= rvice attacks such as opensips PIKE module (
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are use= d to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > efficiently drop SIP= message from badly behaving clients.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Best Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > _____________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Roman Shpount
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Fri, Jun 5, 2020 = at 3:46 AM Christer Holmberg <christer.holmberg=3D
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 40ericsson.com@dmarc.ietf.or= g <mailto:40ericsson.com@dmarc.ietf.org> <mailto:40ericsson.com@dmarc.ietf= .org <mailto:40ericsson.com@dmarc.ietf.org>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Hi,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> If what you desc= ribe is a technical bug that causes interoperability
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> problems, then i= t is within the scope.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> However, if ther= e is a rogue UAS, the UAC can simply terminate the session.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Christer
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> -----Original Me= ssage-----
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> From: OKUMURA Sh= inji <ietf.sh= inji@gmail.com <mailto:ietf.shinji@gmail.com> <mailto:ietf.shinji@gmail.com <mailto= :ietf.shinji@gma= il.com>>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Sent: perjantai = 5. kes=C3=A4kuuta 2020 10.34
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> To: sipcore@ietf.org <mailto:<= a href=3D"mailto:sipcore@ietf.org" target=3D"_blank">sipcore@ietf.org&g= t; <mailto:sipcore= @ietf.org <mailto:sipcore@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Cc: Christer Hol= mberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com> <mailto:christer.holmberg@ericsson.com <mailto:christer.holmberg@ericss= on.com>>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Subject: RFC4028= : bug in 11 Security Considerations
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Hi,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> 11.=C2=A0 Securi= ty Considerations
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 Next, consider the case of a rogue UAS that wishes to force a UAC to >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 generate refreshes at a rapid rate.=C2=A0 In that case, the UAC has to<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 support session timer.=C2=A0 The initial INVITE arrives at the rogue UA= S,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 which returns a 2xx with a very small session interval.=C2=A0 The UAC u= ses
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 this timer and quickly sends a refresh.=C2=A0 Section 7.4 requires that=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 the UAC copy the current session interval into the Session-Expires
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 header field in the request.=C2=A0 This enables the proxies to see the<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 current value.=C2=A0 The proxies will reject this request and provide a=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 Min-SE with a higher minimum, which the UAC will then use.=C2=A0 Note,<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 that if the proxies did not reject the request, but rather proxied
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 the request with a Min-SE header field, an attack would still be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 possible.=C2=A0 The UAS could discard this header field in a 2xx respon= se
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 and force the UAC to continue to generate rapid requests.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> If the rogue UAS= returns again a 2xx with a very small session interval,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> the attack will = continue. To prevent this case, I think the UAC and proxies
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> SHOULD make sure= that the SE-value and MSE-value in the response are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> greater than or = equal to the MSE-value in a sent request. And ... what
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> should the UAC a= nd proxies do? Should they modify the response?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Is this included= in the scope of the bis?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> Shinji
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> ________________= _______________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> sipcore mailing = list
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> sipcore@ietf.org <mailto:sipcore@ietf.org> &= lt;mailto:sipcore@iet= f.org <mailto:= sipcore@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org/mailman/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>
--00000000000024c1f105a7a11365-- From nobody Tue Jun 9 01:45:13 2020 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 939EF3A0AEC for ; Tue, 9 Jun 2020 01:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHiYPF-44wb8 for ; Tue, 9 Jun 2020 01:45:10 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 747DD3A0976 for ; Tue, 9 Jun 2020 01:45:10 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id b16so9756629pfi.13 for ; Tue, 09 Jun 2020 01:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AE1mmNHxl7O52CqSFFc9ARMEXYn+3NzSx7OJ3GqEhjY=; b=NWmbXw/VhTbdiYi+wvpTav6edFrAro2la+/EnrCabf7IRpl2AhHqtZNL1ogWYpPmIh o6HbNQB2H/o5qbmxlRr73PdW2ATbhrzE+NOrSsNeIYXJkiNOP9ZJuiFsSghMmc1p2e8/ IGQ3HvrMYLNB7jqFTGWFRF/fOxlvIhuXZpTGAwb7rPp+Zr0WtcKegtDrsbw1f+dnHAng yvlzLS7b8Tp7iVLxjJ49F+d4UBHszXmHq5KhOxKGn7G1+mHYJ7S6n9Q8JFtmUWiWFuRD lZMc+ETkL5fgVW+5lFIVwKa7z1UpkvDl9PB1uFO8IWm0TGAWaFHwj5eH+pmbrz5XR5TZ XSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=AE1mmNHxl7O52CqSFFc9ARMEXYn+3NzSx7OJ3GqEhjY=; b=aE3hkNziySx/CXLkt11u7ToYO+M65KHGgUv6hcHUVILKlLUuGJrOVxvqsNSObuhPsh ZdunDF0elVygemht6GI/g0ygQgGW7h0GfleSknIr19z7f/yn6W/9Tk7oKPIdlN4WrdoY EhAJMqwltgphjrlrw0I75KztaWkEu4O7inrXb36odea9l71XAJsFShPt3wftROf7A6gD s0VOhar7tpjC1ksSyoqq1D/z9P2fymI5hYRm7KQhZvKS4imxyKKkAj8JRBuAgWXQSNX7 35wEZdxLSQOazUWA8HXWTpgED0J9I8v/5S1HcUegQWag/oNcwzCX7izq4jDiw3W7K+Vl 5+jA== X-Gm-Message-State: AOAM531udOCT6Zy2qM0N5AhMS71jmJtChl6GDQQix5u/RRvDv4qgeVir M2N2X948JHCSOPM1UXq1zHhSQWBm X-Google-Smtp-Source: ABdhPJw6yGlPcSK2JcFSYdbmgGeKPekkBfYnExjR6X8ZbEt6oy8kjI/Cu9ta7oH9tkr5KaMsPmPfKQ== X-Received: by 2002:a63:d412:: with SMTP id a18mr23324001pgh.154.1591692309293; Tue, 09 Jun 2020 01:45:09 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id y18sm9232272pfn.177.2020.06.09.01.45.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 01:45:08 -0700 (PDT) To: "sipcore@ietf.org" From: OKUMURA Shinji Message-ID: Date: Tue, 9 Jun 2020 17:45:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : Errata id 1687 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 08:45:12 -0000 Hi, Errata ID: 1687 Status: Held for Document Update https://www.rfc-editor.org/errata/eid1687 Section 9 says: ======================================================================== The UAS MUST NOT increase the value of the Session-Expires header field. ======================================================================== It should say: ======================================================================== same as session 8.1 If the request doesn't indicate support for the session timer but contains a session interval that is too small, the UAS cannot usefully reject the request, as this would result in a call failure. Rather, the UAS SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the UAS SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The UAS MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field ======================================================================== Will you fix this errata? Regards, Shinji From nobody Tue Jun 9 02:20:39 2020 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 5FEEF3A0C76 for ; Tue, 9 Jun 2020 02:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8eOEiT7bcBD for ; Tue, 9 Jun 2020 02:20:33 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 A238B3A0C5A for ; Tue, 9 Jun 2020 02:20:33 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id d10so10057833pgn.4 for ; Tue, 09 Jun 2020 02:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LKFmr/Wng7mXyIAbjgDfNycx0LPttv0J4cp9Yx0MmWc=; b=HWCoM6BZUHIQb+dchMzdf3QtQm0vYqOob6obCtEXBBVuuGYRhGbF985PFParYSJRb5 RX6y3gTQKXmQySuIUcEpgHEFCaMvzehWRj19O4JXAiRUAAGDCFMii2WEBarXut9KUWqS XwZmG6W73UzQE9YB5ic+wwJeva2qmiVrEaS5I2waN3ToxzqZGqRv6L9/RYRLLAba8by3 s6NxxRryEQjhzxwLSK5qG21CZ0TmUGnYOD/UvE+b7HxhUt+KEm6obUstLF95p0BvApAl zpcN0iH78Wzl0WcYl/z28l0aX/esJCQQHpVnypgZDMznXI4nuecZB5se+VLn9tDA7H+8 ZFIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LKFmr/Wng7mXyIAbjgDfNycx0LPttv0J4cp9Yx0MmWc=; b=mrPwnvco29XfFqpCR6U9l4uS/BOW3BR9YQubOxC5GgNz6DxvYMya2Q4yf7SYow8+kr XTBeDoe1zNhrkuPa4Z56lZPh7h7vU+j+IPjDw6XZpnvJ05AJHKfqnT7C8Pgi+R/z4yR1 N8+2hSnjvRO8fWHFkoDNepxCsAHRdxc4Fu0NxLJkTxsgbE2rgCKEpV2BwKWi0VE6aMcI WkdIB5Tgl6Y61yMWc4o3PHYonZ7ezjGyQpJ+nJ4zu+WQ/1asXoREMHATMX9dnH4RbkI0 lG4vIntGPNxGRtGNwJVaJ9PRZvtMbWV6K7VQzZhTICXTIOzISwE92Onuzd4xwDtZnwCM 2zcw== X-Gm-Message-State: AOAM531mneSpVYu8Q8mhcOikzcf0Q9IrwiyQXvsFYWTETjCMc6LLXXtQ /uCMgtcYuA3q4HNOjcDkbqU= X-Google-Smtp-Source: ABdhPJyWdC4Mv88/OJxmZRmDsMoZVG4pk/2+LhlS6gKyQuOzmYdFuTHL2QJCoA/ubE4LjGlE6C8RpA== X-Received: by 2002:a62:248:: with SMTP id 69mr25384872pfc.243.1591694433049; Tue, 09 Jun 2020 02:20:33 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id u12sm1875104pjy.37.2020.06.09.02.20.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 02:20:32 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Roman Shpount References: <95f31631-bf7f-2e2b-67da-f2f8d44c7e57@gmail.com> <7e27adb7-08b3-9467-f637-fd4cc2e05c68@gmail.com> Message-ID: <459a5cd2-edfc-6151-f449-6cad183351fd@gmail.com> Date: Tue, 9 Jun 2020 18:20:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of "cleared" in 7.4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 09:20:37 -0000 Roman, And more interesting, if P2 is not present in a dialog, SE may be lower than 900. But I've not seen. To be exact, I wouldn't notice it, if it happens. Regards, Shinji On 2020/06/09 15:37, Roman Shpount wrote: > On Tue, Jun 9, 2020 at 2:11 AM OKUMURA Shinji > wrote: > > The session-timer glare is the main scope, I see. I see also a new invention is out of scope, but Errata, bug-fix and clarification are in the scope. 4028bis does not only update RFC4028, but obsoletes it. Also, I don't think a full revision is necessary. If necessary, I will write it. > > > I think clarifications are in-scope and they address real issues in the field. > > For my example, there are other proxies omitted from the diagram. > P1 reduces SE to 300. > P2 rejects by 422. > > > I see. This is interesting since this will cause subsequent UPDATE to be refused with 422 by the proxy P2 and then resent  by UAC with higher Min-SE and lower SE value. > > Do you see this happening in practice? > > Thank You, > _____________ > Roman Shpount From nobody Tue Jun 9 19:56:44 2020 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 266283A091B for ; Tue, 9 Jun 2020 19:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6OplJR2W7SPf for ; Tue, 9 Jun 2020 19:56:39 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 801003A0881 for ; Tue, 9 Jun 2020 19:56:39 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id k2so252815pjs.2 for ; Tue, 09 Jun 2020 19:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GSVr+k+OjBs12Qj421aXOxuXKN0YfbdoCSTSB8hyNO0=; b=Fs1JVG4AB1bLn4pYK/QhqtCofFsmzycC7S2vUCpELHoCGGBV52qDMmA+BHIGcHPMWJ Ho47djBuvizoO857hOSibdBJRt3smg4kOQqkWSOL2fLwtfFq4+cM7sldXH2cvLikbuci EMm9psH6QFP6Bmu4RPfU/liKa0D+wC6ZkGh+eCsOjkAolCSHrJ8Sg3iwvGivRqVk5rVl e8RlJB4mBUJRSz3Lgf1n9GCYp01G2rVvwogOWMQPOt5oSZBpzSswI34k2rzopfgXdFOb KNQkVZEytb83Cm0PrKPiMFaHCooRbAVuTeDL5CiU1sspp/g6Csg9JyZxvMgL+jwmq4vv IEzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GSVr+k+OjBs12Qj421aXOxuXKN0YfbdoCSTSB8hyNO0=; b=MBEioiDKiSTAMYFCk+Kbu6aZH12re3ApP+RZO9/dlSHYPAKinMh8qOTQWBgxUHkTiv psxkPHNL34d/sznwHxvn9usfGGXWXUNJTIeXoQ9RpnEP1Wj/k1uozZ+t1yuSCEiaOwqt bPdTiiOgDw/SlrIVe+OmxB3RSZQXbtUoIn/JXEbNEO1xe+z0+Yw8jUDigg5hKm2pl+0t AgmLkQs8rLaUA3dxsyUuK8PsbgtvGoxoYowK4drHrECdwN0P3CLxBayQUkmGRtJbUG70 OE2wzvNj9U9V4Jh2sM5n6rTr8HpDq2Ovo6poeXIqQ0qXshAoOGmF+tS7dxEpJ7nMH4JO DJSg== X-Gm-Message-State: AOAM530LIRZsomhSbe6zeToFByVv4wtbIkiuoce0DI39sB2DNom0E8sZ X2b9I8ZQDoNwvtl9p86Nae/Nw+8W X-Google-Smtp-Source: ABdhPJwq+cLzB2uJeOqknHsOHZZMebGRLrZpuI1hx0fXZQkYZdnTn3MReX1FXRMlsuc7Q66QijRZDg== X-Received: by 2002:a17:90b:3004:: with SMTP id hg4mr953127pjb.208.1591757797981; Tue, 09 Jun 2020 19:56:37 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id g9sm11122414pfm.151.2020.06.09.19.56.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 19:56:37 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount , Christer Holmberg References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> From: OKUMURA Shinji Message-ID: <64cfde8e-7361-dbad-1d8d-282f34b09cae@gmail.com> Date: Wed, 10 Jun 2020 11:56:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 02:56:42 -0000 Roman, Fortunately. I've not seen this problem. I don't think it really matters if it really happens. It's too late to rewrite the RFC after things happen. When this security concern is left unchanged, as I noted previously, UAC may be satisfied with the SE value and start a session timer. In that case, there will be an infinite loop of 422 responses and the UAS returning a 200 response with a short SE value. You argue that this overload does not need to be dealt with because the proxy handles it by other means. I don't deny that solution either, but I don't see any harm in defining how it should be handled within the protocol as well. On the other hand, you argue that my suggestion causes a disconnect after connecting. Even if it did, would that be a problem? You are arguing that the call should be disconnected. #In a way, this seems to be another infinite loop. Regards, Shinji On 2020/06/09 15:45, Roman Shpount wrote: > Shinji > > I am saying this issue is not a real issue since it should not affect any real deployments. Do you see this causing problems anywhere? > > Your solution, on the other hand, is potentially problematic since it will cause a call to connect and then drop due to session timer expiration. I would prefer normative behavior would not change unless someone is actually affected by this. Any proxy which deals with untrusted UA should already deal with this problem using denial of service protection. UAC should disconnect the call if Session-Expires is less then it is willing to support. > _____________ > Roman Shpount > > > On Tue, Jun 9, 2020 at 1:59 AM OKUMURA Shinji > wrote: > > Roman, > > This issue occurs really when current RFC-compliant UAC and proxies encounter such UAS. I don't know why you don't think this is a problem. And I don't like the policy that we don't have to do anything, as a good proxy will solve all the issues. > > Regards, > Shinji > > On 2020/06/09 5:49, Roman Shpount wrote: > > Shinji, > > > > Yes, only proxy is going to notice the problem, but since proxy needs to deal with denial of service attacks anyway, it will deal with clients that set Session-Timer to a value which is too small. > > > > My view is that Min-SE is advisory. UA can disregard both Min-SE and Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy would need to gracefully deal with it. We can update security considerations to mention this, but once again, unless this is causing known interop issues, I would prefer not to touch this. > > > > Best Regards, > > _____________ > > Roman Shpount > > > > > > On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji >> wrote: > > > >     Hi, > > > >     Sometimes only a proxy can notice the problem. If the value returned by a UAS is fine for the UAC, the UAC does not notice the problem. > > > >     Regards, > >     Shinji > > > >     On 2020/06/08 17:19, Roman Shpount wrote: > >      > Shinji, > >      > > >      > My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests. > >      > > >      > Best Regards, > >      > _____________ > >      > Roman Shpount > >      > > >      > > >      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji > >>> wrote: > >      > > >      >     Hi, > >      > > >      >     A 200 response has no Min-SE header. > >      > > >      >     My suggestion is below. > >      > > >      >     In this case, the UAC and proxies should follow the procedures defined > >      >     in section 7.2 and 8.2 as if the Session-Expires header field were not > >      >     in the 2xx response. > >      > > >      >     Regards, > >      >     Shinji > >      > > >      >     On 2020/06/05 18:35, Roman Shpount wrote: > >      >      > Proxy, if it receives a 2xx response with Min-SE header set to a value > >      >      > lower then Min-SE set by the proxy in the corresponding request, should > >      >      > increase Min-SE to the desired proxy value. > >      >      > > >      >      > UAC, if it receives a 2xx response with Session-Expires set to a value > >      >      > below Min-SE in the response or original request from the UAC. should > >      >      > immediately terminate a call. > >      >      > > >      >      > Unfortunately, proxy has no graceful way to terminate a call, so if both > >      >      > UAC and UAS are rogue, this will result in frequent session refresh > >      >      > transactions. > >      >      > > >      >      > In practice, this is not an issue, since proxy, when communicating with > >      >      > untrusted end points, typically have a some sort of dynamic rate limiter to > >      >      > prevent denial of service attacks such as opensips PIKE module ( > >      >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to > >      >      > efficiently drop SIP message from badly behaving clients. > >      >      > > >      >      > Best Regards, > >      >      > _____________ > >      >      > Roman Shpount > >      >      > > >      >      > > >      >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg >      >      > 40ericsson.com@dmarc.ietf.org > >>> wrote: > >      >      > > >      >      >> Hi, > >      >      >> > >      >      >> If what you describe is a technical bug that causes interoperability > >      >      >> problems, then it is within the scope. > >      >      >> > >      >      >> However, if there is a rogue UAS, the UAC can simply terminate the session. > >      >      >> > >      >      >> Regards, > >      >      >> > >      >      >> Christer > >      >      >> > >      >      >> > >      >      >> > >      >      >> -----Original Message----- > >      >      >> From: OKUMURA Shinji > >>> > >      >      >> Sent: perjantai 5. kesäkuuta 2020 10.34 > >      >      >> To: sipcore@ietf.org > >> > >      >      >> Cc: Christer Holmberg > >>> > >      >      >> Subject: RFC4028 : bug in 11 Security Considerations > >      >      >> > >      >      >> Hi, > >      >      >> > >      >      >> 11.  Security Considerations > >      >      >>      Next, consider the case of a rogue UAS that wishes to force a UAC to > >      >      >>      generate refreshes at a rapid rate.  In that case, the UAC has to > >      >      >>      support session timer.  The initial INVITE arrives at the rogue UAS, > >      >      >>      which returns a 2xx with a very small session interval.  The UAC uses > >      >      >>      this timer and quickly sends a refresh.  Section 7.4 requires that > >      >      >>      the UAC copy the current session interval into the Session-Expires > >      >      >>      header field in the request.  This enables the proxies to see the > >      >      >>      current value.  The proxies will reject this request and provide a > >      >      >>      Min-SE with a higher minimum, which the UAC will then use.  Note, > >      >      >>      that if the proxies did not reject the request, but rather proxied > >      >      >>      the request with a Min-SE header field, an attack would still be > >      >      >>      possible.  The UAS could discard this header field in a 2xx response > >      >      >>      and force the UAC to continue to generate rapid requests. > >      >      >> > >      >      >> If the rogue UAS returns again a 2xx with a very small session interval, > >      >      >> the attack will continue. To prevent this case, I think the UAC and proxies > >      >      >> SHOULD make sure that the SE-value and MSE-value in the response are > >      >      >> greater than or equal to the MSE-value in a sent request. And ... what > >      >      >> should the UAC and proxies do? Should they modify the response? > >      >      >> > >      >      >> Is this included in the scope of the bis? > >      >      >> > >      >      >> Regards, > >      >      >> Shinji > >      >      >> _______________________________________________ > >      >      >> sipcore mailing list > >      >      >> sipcore@ietf.org > >> > >      >      >> https://www.ietf.org/mailman/listinfo/sipcore > >      >      >> > >      >      > > >      > > > > From nobody Wed Jun 10 04:30:16 2020 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 018AA3A096A for ; Wed, 10 Jun 2020 04:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 w87aD0HUDcoH for ; Wed, 10 Jun 2020 04:30:13 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2062.outbound.protection.outlook.com [40.107.21.62]) (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 1918D3A096B for ; Wed, 10 Jun 2020 04:30:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oj0qPUdmjGeboLMV6y0qC1pTi0fsm1mSwTs1wUyKN61PyA3QdlVeJs+GElls1hpJsgNJhOCkMxYR02qQMfPYE4h9JwIyjs7OhGMcX7ZokYD0Di3roQW+HopvIL+XQtAIZEPx5dEr3jqBP7gDPCeAQo71vpMlVubRTEbW5ls+yDOOIHoLC92oHzqfrrMTsb2dUFdAz5FPkA5kz036SUB30xp+IL9Lq4zd6qoa0GtvEU4csX+0r2lav59ZsKMoD7PySZep8j8MBCRCZzI85lcFzy/tMBWuwVAFwTK2ypVunhBhXBfB0SXPRxekRY7zX9Uz9+fLMgL7n46jrfpQC8+Pzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BR+DDObqXHI+Oj0j8CA4z1wgvzCyZsnL5a/ZJZ+y8Os=; b=Q5LcHrS78iUFJ95aLjATSyPCqV+HTq+a+mhI0Nu+1KDnAyCHM0l8lQ3HuQfYPO63qKlKe5QfAy37mnYioq26E9rQg7WKgHvY+LQmLFkXLi69jR9M8jsURkWU8LDqPT+zn/iKh2IRw2qLO8Zpnmi1SgeCsVX0Q6f26M32oS6PK9Dm1RSrxNAC1M2gXkmktly/c1L6ZxIXaPBMpGwjYMWlrC0j7h0ft/GyZokgotkVg9GuyjUHzZgn3xuBPNVJmJyA81Sf8R5vrbVrI+sIq0JYjahW0me8Zr4kpiYHCJBevSVUIrp/SFE+wyZeWTZ/rz2krRqnjF4PCq8e7lI5xgT1OA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BR+DDObqXHI+Oj0j8CA4z1wgvzCyZsnL5a/ZJZ+y8Os=; b=li6v+ybrqGKsMW3OD8HZ4vQGp2WJYpmBYojvRFbBqvAjkp3KaImARJ+tNxpK586j7dAAtinBbhXRVnjp8lrcJaJaVONoB9Zje269P8LpFn2RR8vpCW4vP/jWHhlVcgPmott17h/zBf+cfv/RnZ9w8HdNwAjk46OEMzc2rCwQelk= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM6PR07MB4053.eurprd07.prod.outlook.com (2603:10a6:209:35::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Wed, 10 Jun 2020 11:30:10 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3088.021; Wed, 10 Jun 2020 11:30:10 +0000 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: RFC4028 : Errata id 1687 Thread-Index: AQHWPjpM92assq5q80Sdejaj+jRpJ6jRuGEg Date: Wed, 10 Jun 2020 11:30:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.105] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7bc2837-a0c1-47b3-694a-08d80d31a25c x-ms-traffictypediagnostic: AM6PR07MB4053: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0430FA5CB7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RIn8Ij5DUmryKkCjSR3kivzend9NlT1h7cxIm8yW5HWKlKdY78Kc6wGu6Jai7Rvh2nNJTThuegU9Os20un9kS/9o/J1MlNkg72wuICGxiFlVwz8b2fp8Z6lfXXue4QtU4E2ssuLp3QRkBXX+2Dp43GnqkiEYskV+4Wwqd+ILb5xIOnIo4WpE6dIWumLPzdmTO6wC7Q1qPkbiwj9H+UJCvsZwg+P01/o4xXsKnQi6QK7Arb+kjW7aplZI2a/9MGgj8wfYNfP4yAVwVIRrSuJZ2+Rp2V1yoUH6RAO3MtxgfxKPIWpMETIVbqaAmRYqjeSC21SzkIixwcegK9axdlXXyAeonk4B5g3inFikGHAQ6ETMu2EfD8hh0jOu1j2ghBptmuAT8gkGiTtcP2T2B4kD4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(966005)(478600001)(26005)(186003)(66446008)(8676002)(76116006)(64756008)(66556008)(9686003)(66946007)(66476007)(71200400001)(2906002)(5660300002)(6506007)(44832011)(52536014)(55016002)(8936002)(7696005)(66574014)(110136005)(83380400001)(33656002)(316002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: E/pmmwL2U6ruK2Plo/61fu4JHGeujLIWBWekD110XoZdd2DY/BqH+5B5i3JfDI27j/YbQFc8zJKxCnAEWa4FV/g072wzrD6jXjXxVwtxnUTGKwD7lOlKl+5CRYMVp+dWbEqGDOrSVYwxBIS17kYiRoGCJabuAxG9H+uEykKMwzsu91rrqSYRCltwTTs9HuiBJwiM9OecpWaVy36KZx6GQEaPcRceS82p0yhZ2Eg6B7JP9X7MvQKJIivkm2s27+VnP2F73PxHgfOfkw4B1H/UnHOdBLdz1wsjhb5tuRyw6So010dVw9ElBoqpQz2hn8xTL8/B5puqEChmbgtYi2cN8IHPTI9zhmVQSO9jPatmuvyMRDlMgm1Eas7Uz20duRaZixbHQLPX0npo+QXv+mOVivGD7N07ML19MBwnWd1NOCE/TbdpwtNKdPaFXnKJL0/oHinu7o2THTZ6xFsNjW+lFqpqxnradHsJl0mXQQnqCPY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7bc2837-a0c1-47b3-694a-08d80d31a25c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 11:30:09.9507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j/B4+41g4xoVkNjwBrxgGmIyqPVi2kY88bPv4VJwopXB7zYoORe2Na2rh+QxNZiKuGCrEE21kcR0ofn4Ra4FmWHpyECQQLKgPH/7iXPKogg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4053 Archived-At: Subject: Re: [sipcore] RFC4028 : Errata id 1687 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 11:30:15 -0000 SGksDQoNCldlIHdpbGwgbG9vayBhdCB0aGUgZXJyYXRhcywgYW5kIHNlZSBob3cvaWYgdGhlIGFs aWduIHdpdGggdGhlIHN1Z2dlc3RlZCB3YXkgdG8gc29sdmUgdGhlIGdsYXJlIHNpdHVhdGlvbi4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IE9LVU1VUkEgU2hpbmppIDxpZXRmLnNoaW5qaUBnbWFpbC5jb20+IA0KU2VudDogdGlpc3Rh aSA5LiBrZXPDpGt1dXRhIDIwMjAgMTEuNDUNClRvOiBzaXBjb3JlQGlldGYub3JnDQpDYzogQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClN1YmplY3Q6 IFJGQzQwMjggOiBFcnJhdGEgaWQgMTY4Nw0KDQpIaSwNCg0KRXJyYXRhIElEOiAxNjg3DQpTdGF0 dXM6IEhlbGQgZm9yIERvY3VtZW50IFVwZGF0ZQ0KaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS92MS91cmw/az0zMTU0NGE1My02ZmY0YWFjYS0zMTU0MGFjOC04NjgyYWFhMjJiYzAtOGEyNDgw NjU4YmRhYzgwNiZxPTEmZT03MjkyMTE0Mi1mZGRhLTRmMzUtODlkZS1mN2NlNmQ2YzVlODgmdT1o dHRwcyUzQSUyRiUyRnd3dy5yZmMtZWRpdG9yLm9yZyUyRmVycmF0YSUyRmVpZDE2ODcNCg0KU2Vj dGlvbiA5IHNheXM6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClRoZSBVQVMgTVVTVCBOT1QgaW5jcmVhc2Ug dGhlIHZhbHVlIG9mIHRoZSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkLg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQoNCkl0IHNob3VsZCBzYXk6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnNhbWUgYXMgc2Vzc2lv biA4LjENCiAgICBJZiB0aGUgcmVxdWVzdCBkb2Vzbid0IGluZGljYXRlIHN1cHBvcnQgZm9yIHRo ZSBzZXNzaW9uIHRpbWVyIGJ1dA0KICAgIGNvbnRhaW5zIGEgc2Vzc2lvbiBpbnRlcnZhbCB0aGF0 IGlzIHRvbyBzbWFsbCwgdGhlIFVBUyBjYW5ub3QNCiAgICB1c2VmdWxseSByZWplY3QgdGhlIHJl cXVlc3QsIGFzIHRoaXMgd291bGQgcmVzdWx0IGluIGEgY2FsbCBmYWlsdXJlLg0KICAgIFJhdGhl ciwgdGhlIFVBUyBTSE9VTEQgaW5zZXJ0IGEgTWluLVNFIGhlYWRlciBmaWVsZCBjb250YWluaW5n IGl0cw0KICAgIG1pbmltdW0gaW50ZXJ2YWwuICBJZiBhIE1pbi1TRSBoZWFkZXIgZmllbGQgaXMg YWxyZWFkeSBwcmVzZW50LCB0aGUNCiAgICBVQVMgU0hPVUxEIGluY3JlYXNlIChidXQgTVVTVCBO T1QgZGVjcmVhc2UpIHRoZSB2YWx1ZSB0byBpdHMNCiAgICBtaW5pbXVtIGludGVydmFsLiAgVGhl IFVBUyBNVVNUIHRoZW4gaW5jcmVhc2UgdGhlIFNlc3Npb24tRXhwaXJlcw0KICAgIGhlYWRlciBm aWVsZCB2YWx1ZSB0byBiZSBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIE1pbi1TRSBoZWFkZXIN CiAgICBmaWVsZA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCldpbGwgeW91IGZpeCB0aGlzIGVycmF0YT8N Cg0KUmVnYXJkcywNClNoaW5qaQ0K From nobody Wed Jun 10 13:35:38 2020 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 C445F3A11FF for ; Wed, 10 Jun 2020 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 MkXKQkMbTyKy for ; Wed, 10 Jun 2020 13:35:35 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2059.outbound.protection.outlook.com [40.107.220.59]) (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 F119D3A11FE for ; Wed, 10 Jun 2020 13:35:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JN2GE5z6pwVrVnMhB/zg3CdUXTvADHd4pdL5Kpd09QUOM7nvAMiwFuk4ECqvzRgN1ClNimaRMK6LzzS+ccH/iNAJSH1kkrfTYoBn4jpf+xW7SRg7kBZAvBtsp5GWQI3upYcqGK4V5NptkOCri8Jwcr5bmigj2NhmYr+wjvuh7NM6LIecfrEWC9e1aXbt8MtEM4ZmDawRRVuN9cA1BE8EhCjUikmCikNOLTKrJ88n4jQFkJp6xgQABWXMplFF/wQ8kneSrPyZ618Wz/FAcuGORQ4bMJsy6s72kjfG1isBD+n4xJhvNX5AjV54ecHBz9b7eOnm4zHBQ994eshew0TiWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HzrZkYO6Y95LUa5nKUVLauMn9zLJMf+nqGeHM1i/p1Y=; b=YLwnvIRIuHTzx7NwU8bkiFHQWuOZt4bt6cVIfsk2we1U9ECsAQjJGs438lr/Z6p1xQhUgOByi4XCKnpxTm0K4gDsuFjCtvsH3IHTnfAmL72QSCjagBqHFZSeYYmcabqMzaBBD7f9IsgbvVuKdXU/EPBu7NGAtaFfbrkZeDauSQAbL5g0llcYAl5gt6RxPA6Q88trES/chjc57HKL0NxyFE13vVLrrYJJdtrYNf4GnAtrSSx3X155HFwNwZk6ARtBB+VAmg0E+BZM+7CIAhgljD7AS1+Fnt+mflGUS/+rmwdogsA3QLfJACt1MFTAFRFEaOWJtcergJUqpBXdnqvgNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HzrZkYO6Y95LUa5nKUVLauMn9zLJMf+nqGeHM1i/p1Y=; b=DyQfkyk2bt144oJHo1L2Ognw3F2sqiFfRCNlb0n0Pvxtd6pzZlsqFdfvofJ63fEeHbqrxVuh95dzXP/+fOC7eVy7//GGHmLISQ/SatLiFIkjx5JjSlmdYGq+ZRc3wE9z9BGX6ftwdv2sXCg3Q6jG0MbWSXgLngKz0qVnDAyHlTM= Received: from CY4PR13CA0025.namprd13.prod.outlook.com (2603:10b6:903:99::11) by CH2PR12MB3718.namprd12.prod.outlook.com (2603:10b6:610:2e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Wed, 10 Jun 2020 20:35:33 +0000 Received: from CY1NAM02FT039.eop-nam02.prod.protection.outlook.com (2603:10b6:903:99:cafe::76) by CY4PR13CA0025.outlook.office365.com (2603:10b6:903:99::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9 via Frontend Transport; Wed, 10 Jun 2020 20:35:33 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT039.mail.protection.outlook.com (10.152.75.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 20:35:32 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05AKZUq3013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 10 Jun 2020 16:35:31 -0400 To: sipcore@ietf.org References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> From: Paul Kyzivat Message-ID: <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> Date: Wed, 10 Jun 2020 16:35:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(376002)(346002)(396003)(136003)(46966005)(53546011)(478600001)(47076004)(8676002)(2906002)(75432002)(15650500001)(70586007)(7596003)(316002)(70206006)(186003)(2616005)(6916009)(66574014)(26005)(336012)(956004)(83380400001)(86362001)(82740400003)(82310400002)(786003)(36906005)(31686004)(5660300002)(8936002)(966005)(31696002)(356005)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 52f1ea85-043e-4a8f-8fe1-08d80d7dd2cd X-MS-TrafficTypeDiagnostic: CH2PR12MB3718: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nnTO6OR6vEJ2oHG1hn8FHE/jZ0g9XObbSGQmjublOC1/SL9JSaXqzqOmT8GPg3A150tx4OHlCLtSyWyuLWTjEpMMjdGwGH/5hfsg53NGkzHihFonmECeQ4ZiL7ZjR87THX3ltKvAkbFT/hXTBjdRooGDRaPydbvpUe27W+w1rrGn7CNS4NCb2/vfDUsONpBBWzCNFtnmmM2cQGuDVs86aRdp0s9wLn+kHDegBYKScrzlniWE/4pIysEDlIcLg7OBcl2UeObXUVkxI+LpP+9ba4ffhFzBl/sOY3xxa/QqSkBnOoJBn6QwdfU3tlRg7YbMdqo9Rw0QNpKdv2zYeKGJegh2O9jcGYxpYICdG5uLvt39SE2L1y4vckLgxYT33binHWXfj/G6HtYco6+BerE2nyKjSp4aVWWknKqkTcoSybQFaIjCuLWtDBJxoeWc5iowcvmwSIj1LgBRboWoKf2EgoiIdcAWPn2uHYL0Ughr8oBdxML0uCFggap4lzgeTmUL X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 20:35:32.8976 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 52f1ea85-043e-4a8f-8fe1-08d80d7dd2cd X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3718 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 20:35:37 -0000 On 6/9/20 1:59 AM, OKUMURA Shinji wrote: > Roman, > > This issue occurs really when current RFC-compliant UAC and proxies > encounter such UAS. I don't know why you don't think this is a problem. > And I don't like the policy that we don't have to do anything, as a good > proxy will solve all the issues. I've been doing my best to keep my mouth shut on this thread. I'm going to violate that once and then go back to being silent. I don't understand the desire to bound the scope so severely. RFC4028 is 15 years old, and the majority of the content is closer to 20 years old. There has been ongoing confusion about it over the entire 15 years. Once the effort is made to open it I find it nonsensical to close it again while leaving known issues untouched. ISTM is whether there is energy to make other fixes. If Shinji is willing to do the work to cover other things then why not accept that work? Thanks, Paul > Regards, > Shinji > > On 2020/06/09 5:49, Roman Shpount wrote: >> Shinji, >> >> Yes, only proxy is going to notice the problem, but since proxy needs >> to deal with denial of service attacks anyway, it will deal with >> clients that set Session-Timer to a value which is too small. >> >> My view is that Min-SE is advisory. UA can disregard both Min-SE and >> Session-Expires and send re-INVITE or UPDATE at any rate it wants. >> Proxy would need to gracefully deal with it. We can update security >> considerations to mention this, but once again, unless this is causing >> known interop issues, I would prefer not to touch this. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji > > wrote: >> >>     Hi, >> >>     Sometimes only a proxy can notice the problem. If the value >> returned by a UAS is fine for the UAC, the UAC does not notice the >> problem. >> >>     Regards, >>     Shinji >> >>     On 2020/06/08 17:19, Roman Shpount wrote: >>      > Shinji, >>      > >>      > My instinct would be to allow Session-Expires header to pass >> through even if it is below Min-SE value, and then let either UAC >> disconnect the call or denial of service filter do its job and drop >> the session if it starts sending too many requests. >>      > >>      > Best Regards, >>      > _____________ >>      > Roman Shpount >>      > >>      > >>      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji >> >> >> wrote: >>      > >>      >     Hi, >>      > >>      >     A 200 response has no Min-SE header. >>      > >>      >     My suggestion is below. >>      > >>      >     In this case, the UAC and proxies should follow the >> procedures defined >>      >     in section 7.2 and 8.2 as if the Session-Expires header >> field were not >>      >     in the 2xx response. >>      > >>      >     Regards, >>      >     Shinji >>      > >>      >     On 2020/06/05 18:35, Roman Shpount wrote: >>      >      > Proxy, if it receives a 2xx response with Min-SE header >> set to a value >>      >      > lower then Min-SE set by the proxy in the corresponding >> request, should >>      >      > increase Min-SE to the desired proxy value. >>      >      > >>      >      > UAC, if it receives a 2xx response with Session-Expires >> set to a value >>      >      > below Min-SE in the response or original request from >> the UAC. should >>      >      > immediately terminate a call. >>      >      > >>      >      > Unfortunately, proxy has no graceful way to terminate a >> call, so if both >>      >      > UAC and UAS are rogue, this will result in frequent >> session refresh >>      >      > transactions. >>      >      > >>      >      > In practice, this is not an issue, since proxy, when >> communicating with >>      >      > untrusted end points, typically have a some sort of >> dynamic rate limiter to >>      >      > prevent denial of service attacks such as opensips PIKE >> module ( >>      >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , >> which are used to >>      >      > efficiently drop SIP message from badly behaving clients. >>      >      > >>      >      > Best Regards, >>      >      > _____________ >>      >      > Roman Shpount >>      >      > >>      >      > >>      >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg >> >      >      > 40ericsson.com@dmarc.ietf.org >> >> > >> wrote: >>      >      > >>      >      >> Hi, >>      >      >> >>      >      >> If what you describe is a technical bug that causes >> interoperability >>      >      >> problems, then it is within the scope. >>      >      >> >>      >      >> However, if there is a rogue UAS, the UAC can simply >> terminate the session. >>      >      >> >>      >      >> Regards, >>      >      >> >>      >      >> Christer >>      >      >> >>      >      >> >>      >      >> >>      >      >> -----Original Message----- >>      >      >> From: OKUMURA Shinji > > >> >>      >      >> Sent: perjantai 5. kesäkuuta 2020 10.34 >>      >      >> To: sipcore@ietf.org >> > >>      >      >> Cc: Christer Holmberg > >> > >> >>      >      >> Subject: RFC4028 : bug in 11 Security Considerations >>      >      >> >>      >      >> Hi, >>      >      >> >>      >      >> 11.  Security Considerations >>      >      >>      Next, consider the case of a rogue UAS that wishes >> to force a UAC to >>      >      >>      generate refreshes at a rapid rate.  In that case, >> the UAC has to >>      >      >>      support session timer.  The initial INVITE arrives >> at the rogue UAS, >>      >      >>      which returns a 2xx with a very small session >> interval.  The UAC uses >>      >      >>      this timer and quickly sends a refresh.  Section >> 7.4 requires that >>      >      >>      the UAC copy the current session interval into the >> Session-Expires >>      >      >>      header field in the request.  This enables the >> proxies to see the >>      >      >>      current value.  The proxies will reject this >> request and provide a >>      >      >>      Min-SE with a higher minimum, which the UAC will >> then use.  Note, >>      >      >>      that if the proxies did not reject the request, >> but rather proxied >>      >      >>      the request with a Min-SE header field, an attack >> would still be >>      >      >>      possible.  The UAS could discard this header field >> in a 2xx response >>      >      >>      and force the UAC to continue to generate rapid >> requests. >>      >      >> >>      >      >> If the rogue UAS returns again a 2xx with a very small >> session interval, >>      >      >> the attack will continue. To prevent this case, I think >> the UAC and proxies >>      >      >> SHOULD make sure that the SE-value and MSE-value in the >> response are >>      >      >> greater than or equal to the MSE-value in a sent >> request. And ... what >>      >      >> should the UAC and proxies do? Should they modify the >> response? >>      >      >> >>      >      >> Is this included in the scope of the bis? >>      >      >> >>      >      >> Regards, >>      >      >> Shinji >>      >      >> _______________________________________________ >>      >      >> 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 Wed Jun 10 14:29:22 2020 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 34E243A1534 for ; Wed, 10 Jun 2020 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 sF-1L8TkWm99 for ; Wed, 10 Jun 2020 14:29:19 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 B6CAE3A1533 for ; Wed, 10 Jun 2020 14:29:19 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id 18so811909ooy.3 for ; Wed, 10 Jun 2020 14:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y260+UPVbXQ392T2Hlmn3z2po1bPZvTzr8Nfx5a4KNI=; b=my4668mqy+Ywgm98gyS4KcuMBicXu+xQuFEY/M2BUBtkR+byqVCc3yM5cfqFlDue1v TB7oDLQTMMPfN0rR56AvaSTZpBvRP2nP27cRGKQwgGMwZbTsi8nKhYwQ3XCP7mG5iedi P9hnUro7YNc+tcuXNygH57hjaDyLbHoyE7DsvbnYJdPJzGkTHJOhfqRdNM+0fw31GbR1 6TESAJ9zwZllbyjRvoh+rGRAC1oE1Dy1veL6YHMmv52Q+3ZcPUBBA9lODedROA7m7RL3 rpsIq6k6oIH2m127fxQH/ZF+wH68HO7LQ048F7GPNnRIDyoL5nohRH44Pz+eVKgGDIlD IDJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y260+UPVbXQ392T2Hlmn3z2po1bPZvTzr8Nfx5a4KNI=; b=lT36n6jdgWjLRdHUCimWn7PnztBC/F7nvaceH/9ZgBtXmrVXI3mY9ap8TDDoz8fUPj uFc4KwjlYEndggLkhwZiXN3xBGSY2Ivamwt8HMZGDejDuAS343VB3BgsO3mu8U9o378O Y59KC7dAokj7a2Lxsg0gb5onhq7Z6UtFaNZUkF+HIWKSvHs856o6BxoTqzgBQnmGOiWa u4M3ewY2TneXX0VPupGK0FHkidTuI7qLcKVowvo9wM/a19LP4tXv0JEBP9/poLlgodkM 9QCV44m4BgCMAoNotoOc2AajAnAXrgO2ZZwyDS8czjAO/QbxwFYMd0krXZuCqblCUBOm vMfA== X-Gm-Message-State: AOAM5302wr/6B2A54NSxTHBW8uQc90Di4YZs2gi0yfGSJgCcQkHPZeeP qASs2nnIl7jhd/rhn7OkA7LTQrl18tU= X-Google-Smtp-Source: ABdhPJwPhx4qNMUGzYleqFEpM3HeIt7sYTpwsBYF1eoumJ+amtCQ7W1qrwYB4cJ/6CrvBTug0PcnTg== X-Received: by 2002:a4a:c292:: with SMTP id b18mr4150507ooq.48.1591824557768; Wed, 10 Jun 2020 14:29:17 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id a12sm261130otl.29.2020.06.10.14.29.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 14:29:16 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id x202so3460657oix.11 for ; Wed, 10 Jun 2020 14:29:15 -0700 (PDT) X-Received: by 2002:aca:d695:: with SMTP id n143mr2753811oig.5.1591824555164; Wed, 10 Jun 2020 14:29:15 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> In-Reply-To: <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> From: Roman Shpount Date: Wed, 10 Jun 2020 17:29:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000027cc0405a7c18945" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 21:29:21 -0000 --00000000000027cc0405a7c18945 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 10, 2020 at 4:35 PM Paul Kyzivat wrote: > On 6/9/20 1:59 AM, OKUMURA Shinji wrote: > > This issue occurs really when current RFC-compliant UAC and proxies > > encounter such UAS. I don't know why you don't think this is a problem. > > And I don't like the policy that we don't have to do anything, as a good > > proxy will solve all the issues. > > I've been doing my best to keep my mouth shut on this thread. I'm going > to violate that once and then go back to being silent. > > I don't understand the desire to bound the scope so severely. RFC4028 is > 15 years old, and the majority of the content is closer to 20 years old. > There has been ongoing confusion about it over the entire 15 years. Once > the effort is made to open it I find it nonsensical to close it again > while leaving known issues untouched. > > ISTM is whether there is energy to make other fixes. If Shinji is > willing to do the work to cover other things then why not accept that work? > > First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be. Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged. Finally, there was a group consensus on what this update was about (fixing session timer glare and session timer configuration when multiple transactions are in progress). We either need to ask a group for consensus to widen the scope or potentially do it in the subsequent update. Best Regards, _____________ Roman Shpount --00000000000027cc0405a7c18945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 10, 2020 at 4:35 PM Paul Kyzi= vat <pkyzivat@alum.mit.edu&= gt; wrote:
On 6/9/20 1:59 AM, OKUMURA Shinji wrote:
> This= issue occurs really when current RFC-compliant UAC and proxies
> encounter such UAS. I don't know why you don't think this is a= problem.
> And I don't like the policy that we don't have to do anything,= as a good
> proxy will solve all the issues.

I've been doing my best to keep my mouth shut on this thread. I'm g= oing
to violate that once and then go back to being silent.

I don't understand the desire to bound the scope so severely. RFC4028 i= s
15 years old, and the majority of the content is closer to 20 years old. There has been ongoing confusion about it over the entire 15 years. Once the effort is made to open it I find it nonsensical to close it again
while leaving known issues untouched.

ISTM is whether there is energy to make other fixes. If Shinji is
willing to do the work to cover other things then why not accept that work?=


First of all, I really think this = is a hypothetical problem which has no good backwards compatible solution. = Fixing it will cause more trouble then leaving it be.

<= div>Second, I am interested in a document update that targets existing inte= rop problems with minimal changes to the rest of the document. This increas= es=C2=A0the chances of the specification actually being implemented. If cha= nges are too drastic (even if they make the document clearer and more reada= ble), there is a much higher chance that implementers=C2=A0will just ignore= the whole update. As far as I am concerned, there are certain things that = make my life easier which I need fixed as quickly as possible. I can accept= things that make other people's lives easier if they do not slow down = the progress of the overall document too much. If something did not cause a= ny real issues over the past 20 years, as far as I am concerned, it can sta= y unchanged.

Finally, there was a group consensus = on what this update was about (fixing session timer glare and session timer= configuration when multiple transactions are in progress). We either need = to ask a group for consensus to widen the scope or potentially do it in the= subsequent update.

Best Regards,
_____________
Roma= n Shpount=C2=A0
--00000000000027cc0405a7c18945-- From nobody Thu Jun 11 18:14:29 2020 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 9874D3A0D0D for ; Thu, 11 Jun 2020 18:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCAJJ0_IzLe6 for ; Thu, 11 Jun 2020 18:14:25 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 8B65B3A0D0C for ; Thu, 11 Jun 2020 18:14:25 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id 185so3336884pgb.10 for ; Thu, 11 Jun 2020 18:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IptW6EMKQt+F5dJUFUDbnZVFpiVl/ZuBu47t4HJ8YS8=; b=Eqcmj+/5/xTISghjw86wi4AgzCvRXNbUj5tJCoFY4q2o/eIobDIUkly2zvs7yKpdBm /2ev6lmIhUzOik/VHQMwMP+c70WfeGkvF4H0JO4/qExaWOTeGpMxQnNuFy7RStOqQToL M7iVk/hFxMAF7jwfOV960t1Lxr9Tx3ZeT7JM0T/KkKgxciuZ6rkalDsi6C3xkJwyVrNT erAUFC+viPZyEKW96IcNSRNbOG9E3aSISKFuTg2JKFjXno/rQUOht9W0I/qXKa1umVmu JbV/kq8Ni+Ha8nHFSG729eIlbjuhzUwC/HERUiowAV2W3hXtNRN6Y8a8iLFRCp6aG9Z5 JNZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IptW6EMKQt+F5dJUFUDbnZVFpiVl/ZuBu47t4HJ8YS8=; b=RjGWfEHaiGXLvDxPYbqVAbCmynl4+jNLUmHzZqgBSyLLXxtE8AIkYKwKdlT0Mjh1Nf HRuP34UG35uGVS0eeD3q9e7pxGj/bS2i+STPin/cn6nmUDxXSA2Dmrn2CPBGf5RRx5vT XYx3rtxhbAtV9A0rrOWBXa9zOy8/fnBjSLJvf14wg/l14UGWfUD3dZ3rwHsru5YVBLBm t43UPsQlVea/i3f2XgVQss+XyOzZKvJZDZbp8uWiUETkialJEVy5JKTRIY5SDqIYZLvH YUiYcKnaieSfBpVCKBhLZ0r9QhjM4EhyEUzheXH051cjxhIXzWog6rXmqEXyz77gLzQy xqZA== X-Gm-Message-State: AOAM532fDgeTfO2ghmMtxE4rrcKgbZ1mcWqriPoONUok6H1JmqHuqhAC JJS5bnFO+KCsifYvxPsncO8= X-Google-Smtp-Source: ABdhPJwyGbfL0km3hgnjZRWR4QK+LlVTJ1RrsYImO2xLJYRxN2fDH97AdkYwrw/ZU/rsZ3yNzGdgog== X-Received: by 2002:aa7:868b:: with SMTP id d11mr9157178pfo.52.1591924464950; Thu, 11 Jun 2020 18:14:24 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 17sm4392910pfn.19.2020.06.11.18.14.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 18:14:24 -0700 (PDT) To: sipcore@ietf.org References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> From: OKUMURA Shinji Message-ID: <7fa9ed89-a5bd-3e52-dfbc-59adad297593@gmail.com> Date: Fri, 12 Jun 2020 10:14:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 01:14:28 -0000 Thank you, Paul. My proposal contains insufficient detail, but I would like to discuss it further here. If necessary, I will try to cooperate in documentation as much as possible. Regards, Shinji On 2020/06/11 5:35, Paul Kyzivat wrote: > On 6/9/20 1:59 AM, OKUMURA Shinji wrote: >> Roman, >> >> This issue occurs really when current RFC-compliant UAC and proxies encounter such UAS. I don't know why you don't think this is a problem. And I don't like the policy that we don't have to do anything, as a good proxy will solve all the issues. > > I've been doing my best to keep my mouth shut on this thread. I'm going to violate that once and then go back to being silent. > > I don't understand the desire to bound the scope so severely. RFC4028 is 15 years old, and the majority of the content is closer to 20 years old. There has been ongoing confusion about it over the entire 15 years. Once the effort is made to open it I find it nonsensical to close it again while leaving known issues untouched. > > ISTM is whether there is energy to make other fixes. If Shinji is willing to do the work to cover other things then why not accept that work? > >     Thanks, >     Paul > >> Regards, >> Shinji >> >> On 2020/06/09 5:49, Roman Shpount wrote: >>> Shinji, >>> >>> Yes, only proxy is going to notice the problem, but since proxy needs to deal with denial of service attacks anyway, it will deal with clients that set Session-Timer to a value which is too small. >>> >>> My view is that Min-SE is advisory. UA can disregard both Min-SE and Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy would need to gracefully deal with it. We can update security considerations to mention this, but once again, unless this is causing known interop issues, I would prefer not to touch this. >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji > wrote: >>> >>>     Hi, >>> >>>     Sometimes only a proxy can notice the problem. If the value returned by a UAS is fine for the UAC, the UAC does not notice the problem. >>> >>>     Regards, >>>     Shinji >>> >>>     On 2020/06/08 17:19, Roman Shpount wrote: >>>      > Shinji, >>>      > >>>      > My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests. >>>      > >>>      > Best Regards, >>>      > _____________ >>>      > Roman Shpount >>>      > >>>      > >>>      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji >> wrote: >>>      > >>>      >     Hi, >>>      > >>>      >     A 200 response has no Min-SE header. >>>      > >>>      >     My suggestion is below. >>>      > >>>      >     In this case, the UAC and proxies should follow the procedures defined >>>      >     in section 7.2 and 8.2 as if the Session-Expires header field were not >>>      >     in the 2xx response. >>>      > >>>      >     Regards, >>>      >     Shinji >>>      > >>>      >     On 2020/06/05 18:35, Roman Shpount wrote: >>>      >      > Proxy, if it receives a 2xx response with Min-SE header set to a value >>>      >      > lower then Min-SE set by the proxy in the corresponding request, should >>>      >      > increase Min-SE to the desired proxy value. >>>      >      > >>>      >      > UAC, if it receives a 2xx response with Session-Expires set to a value >>>      >      > below Min-SE in the response or original request from the UAC. should >>>      >      > immediately terminate a call. >>>      >      > >>>      >      > Unfortunately, proxy has no graceful way to terminate a call, so if both >>>      >      > UAC and UAS are rogue, this will result in frequent session refresh >>>      >      > transactions. >>>      >      > >>>      >      > In practice, this is not an issue, since proxy, when communicating with >>>      >      > untrusted end points, typically have a some sort of dynamic rate limiter to >>>      >      > prevent denial of service attacks such as opensips PIKE module ( >>>      >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to >>>      >      > efficiently drop SIP message from badly behaving clients. >>>      >      > >>>      >      > Best Regards, >>>      >      > _____________ >>>      >      > Roman Shpount >>>      >      > >>>      >      > >>>      >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg >>      >      > 40ericsson.com@dmarc.ietf.org >> wrote: >>>      >      > >>>      >      >> Hi, >>>      >      >> >>>      >      >> If what you describe is a technical bug that causes interoperability >>>      >      >> problems, then it is within the scope. >>>      >      >> >>>      >      >> However, if there is a rogue UAS, the UAC can simply terminate the session. >>>      >      >> >>>      >      >> Regards, >>>      >      >> >>>      >      >> Christer >>>      >      >> >>>      >      >> >>>      >      >> >>>      >      >> -----Original Message----- >>>      >      >> From: OKUMURA Shinji >> >>>      >      >> Sent: perjantai 5. kesäkuuta 2020 10.34 >>>      >      >> To: sipcore@ietf.org > >>>      >      >> Cc: Christer Holmberg >> >>>      >      >> Subject: RFC4028 : bug in 11 Security Considerations >>>      >      >> >>>      >      >> Hi, >>>      >      >> >>>      >      >> 11.  Security Considerations >>>      >      >>      Next, consider the case of a rogue UAS that wishes to force a UAC to >>>      >      >>      generate refreshes at a rapid rate.  In that case, the UAC has to >>>      >      >>      support session timer.  The initial INVITE arrives at the rogue UAS, >>>      >      >>      which returns a 2xx with a very small session interval.  The UAC uses >>>      >      >>      this timer and quickly sends a refresh.  Section 7.4 requires that >>>      >      >>      the UAC copy the current session interval into the Session-Expires >>>      >      >>      header field in the request.  This enables the proxies to see the >>>      >      >>      current value.  The proxies will reject this request and provide a >>>      >      >>      Min-SE with a higher minimum, which the UAC will then use.  Note, >>>      >      >>      that if the proxies did not reject the request, but rather proxied >>>      >      >>      the request with a Min-SE header field, an attack would still be >>>      >      >>      possible.  The UAS could discard this header field in a 2xx response >>>      >      >>      and force the UAC to continue to generate rapid requests. >>>      >      >> >>>      >      >> If the rogue UAS returns again a 2xx with a very small session interval, >>>      >      >> the attack will continue. To prevent this case, I think the UAC and proxies >>>      >      >> SHOULD make sure that the SE-value and MSE-value in the response are >>>      >      >> greater than or equal to the MSE-value in a sent request. And ... what >>>      >      >> should the UAC and proxies do? Should they modify the response? >>>      >      >> >>>      >      >> Is this included in the scope of the bis? >>>      >      >> >>>      >      >> Regards, >>>      >      >> Shinji >>>      >      >> _______________________________________________ >>>      >      >> 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jun 11 18:48:05 2020 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 DA4623A0E0C for ; Thu, 11 Jun 2020 18:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NGoeB4mJmwf for ; Thu, 11 Jun 2020 18:48:02 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 59C443A0E08 for ; Thu, 11 Jun 2020 18:48:02 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id i12so2988048pju.3 for ; Thu, 11 Jun 2020 18:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pPzmedk2QdhUszqLFx9Z4BGkG5xdRtywSG956kh4JhU=; b=hVcfbLEZ1BOugmnq4UnzFf3jLhJ7mkT+Yeo/4QDMUpvWGY/2qGrXsz3ssc7AVeO+wQ CxfMLcChey0rHj2MOfpCzXj9nZxw1WqjB9fJ4Twlf7jzJJUGssQyLsnUjUkkwgF4gzJK EyMTriYXFxlyw8t2LPb9bcRzO83qpIlIzypkzxgwqDm85HzmdPiJ3RrPNUZj79jr60a6 wFhdNAK1U+wdvy8zT1usGmRbIfKL4JmbPRWXuPTNkSLk4tbgz0Vj8rvx0gZOfgzo9KmS xy3ZXlyKwKSVZAyHEI1LBBtLWUuD42ZvFjuaTanAAraVr9/glEqp60dP51qfw1xdBpZN eYpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pPzmedk2QdhUszqLFx9Z4BGkG5xdRtywSG956kh4JhU=; b=F/RX3H23bOoxqj3u6kZWXFlVSgReC2XVkPLa8r7u+i6k9UOAVF2nSQHzwdMcvGdqlW NUbH2eP9ZRoih1J26OdjATbjB112Yy5ruFicskuwoTS/qFTTT/6mRScn55VbtXnHdOdq fc5n4kq16ndJXuywxRP2ifO0h+wXOR2ipspH/cqdBM1E/OnM7BQRdqrILvBAwpWyomwW zB8IizSJ4XLgrpCHqq+dRJlx6U28V1TK9r3qeY31AJrPWb17fm9n7mK8uJGueEJYl2M7 lW/Z4EW48avKT+Pc4DUd03JTkBU1OjDDmFzwVOZLTFm9PuYCMw3K5VIxTzaNqMCF73zW L0+w== X-Gm-Message-State: AOAM530QTBFrYwjMFTiPz7XpFD5/5mTjSOMuzfbN2oXzGrqTvzTBYxXL /p9IrB/vFOkDC3eXPEEjVO8= X-Google-Smtp-Source: ABdhPJwM1J7tqMbMUYG02jM6hWYaimIcVd+tntojKIFusoLEPYojH98n4PdPZZe7BQ7mEJg+4u0vww== X-Received: by 2002:a17:902:c3cb:: with SMTP id j11mr9914040plj.171.1591926481776; Thu, 11 Jun 2020 18:48:01 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id gt22sm8663018pjb.2.2020.06.11.18.48.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 18:48:01 -0700 (PDT) To: SIPCORE Cc: Roman Shpount , Paul Kyzivat References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> From: OKUMURA Shinji Message-ID: Date: Fri, 12 Jun 2020 10:47:57 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 01:48:04 -0000 Hi, > First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be. If you think that my proposal has no good backwards compatible solution, please point out your concerns more specifically. So we can proceed with the discussion. > Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged. We've waited 20 years, so it doesn't matter if it takes a few more months... What do you need to fix as quickly as possible? > Finally, there was a group consensus on what this update was about (fixing session timer glare and session timer configuration when multiple transactions are in progress). We either need to ask a group for consensus to widen the scope or potentially do it in the subsequent update. It will be needed. Regards, Shinji On 2020/06/11 6:29, Roman Shpount wrote: > On Wed, Jun 10, 2020 at 4:35 PM Paul Kyzivat > wrote: > > On 6/9/20 1:59 AM, OKUMURA Shinji wrote: > > This issue occurs really when current RFC-compliant UAC and proxies > > encounter such UAS. I don't know why you don't think this is a problem. > > And I don't like the policy that we don't have to do anything, as a good > > proxy will solve all the issues. > > I've been doing my best to keep my mouth shut on this thread. I'm going > to violate that once and then go back to being silent. > > I don't understand the desire to bound the scope so severely. RFC4028 is > 15 years old, and the majority of the content is closer to 20 years old. > There has been ongoing confusion about it over the entire 15 years. Once > the effort is made to open it I find it nonsensical to close it again > while leaving known issues untouched. > > ISTM is whether there is energy to make other fixes. If Shinji is > willing to do the work to cover other things then why not accept that work? > > > First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be. > > Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged. > > Finally, there was a group consensus on what this update was about (fixing session timer glare and session timer configuration when multiple transactions are in progress). We either need to ask a group for consensus to widen the scope or potentially do it in the subsequent update. > > Best Regards, > _____________ > Roman Shpount > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Jun 12 00:16:51 2020 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 C837E3A0C77 for ; Fri, 12 Jun 2020 00:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 LFYwzC1w64vv for ; Fri, 12 Jun 2020 00:16:48 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 2E4FA3A0C71 for ; Fri, 12 Jun 2020 00:16:48 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id n70so6629679ota.5 for ; Fri, 12 Jun 2020 00:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HXIjeiiXB5ymHZttimLA6uWbrSFP3898TqcuXNja5HU=; b=ItritEuPhOuz/Wm+caEVigzjTg+6Qhb63rGaEaIr49hYHqP2W1NxDC2DBIucVlwRwR vPsVsdharA1+l3/O+TlnLxmlQ3VSkoU+vfm3QWcSWxqnCHLIGRFsKvZrWZOHbP41gZNP GBF7pBcneL+BeaqdmFo1uFL63bRbS8vWjyKqMo6sKaVHY224YzsQE+oJ+KYinvJ/bvvo fPyoXCWZqTNZxyEM9WvGp0fUj41uGxqOiVeLOp3VtPol8qfISDvDAxI1YuMgdxTAM4yu imSzKt7e9aKNjr9HF0arP+ED1oJZvmgoYZOPRNoFfWKFTejiHIbN62zWWOu1SlsQ9v6R bKzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HXIjeiiXB5ymHZttimLA6uWbrSFP3898TqcuXNja5HU=; b=Qd8V7m62qJGj74xsg9M0HKbyqY6pyGAZiLU2rrphJtK9cpUoMABBQcukG1iUJ0UYs2 GD54Okn0spmVwKo4MTioq5QTUEtIgf1Q90FZd2H5OlSRfOgQk9lX6s18c1ypdMKiN+Ba 54Qay15Qr/K8MTpORgL2G16tFpxPUYw0lnFus6lgiDf6HWfuW8MAOpIFfzzn4AqVdlql cxEgejGfaJd2/yNa7C2yM82IS+Nn/n7vFx6OqIu7TyHyKWVGY9nRZY0VYNxAwR2g9LIL MlABFWJxnongZT5P0papSTCrzqjajMCfSPmdwyh3Ly8EMNlPO3aRz7+FnKQOCTxFDMkm I4/w== X-Gm-Message-State: AOAM531dmAfEPpUYcZYxs1X13+//o+uLyiYL/wgY6G9XWuwyNK/vRjiM 1maEz8YputZ5WhoFMHhUEbu0jbO4Pa0= X-Google-Smtp-Source: ABdhPJyAqUWvVK0IHkflwK5lnjctG97TTanrgFZedWNdVjoPxB5IZahV+4djfPf2N2YL1qyTps+nZQ== X-Received: by 2002:a9d:1727:: with SMTP id i39mr9472840ota.367.1591946206498; Fri, 12 Jun 2020 00:16:46 -0700 (PDT) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com. [209.85.167.170]) by smtp.gmail.com with ESMTPSA id e17sm1190517oiy.21.2020.06.12.00.16.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 00:16:45 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id a137so7857447oii.3 for ; Fri, 12 Jun 2020 00:16:45 -0700 (PDT) X-Received: by 2002:aca:72c2:: with SMTP id p185mr1206091oic.139.1591946204848; Fri, 12 Jun 2020 00:16:44 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> In-Reply-To: From: Roman Shpount Date: Fri, 12 Jun 2020 03:16:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , Paul Kyzivat Content-Type: multipart/alternative; boundary="0000000000000aa8bf05a7dddc07" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 07:16:50 -0000 --0000000000000aa8bf05a7dddc07 Content-Type: text/plain; charset="UTF-8" Shinji, First of all, we are dealing with a situation where a lot of original SIP shortcomings prevent us from developing a good fix. Specifically the following things makes good implementations of session timer possible: 1. Session Timer should have been required. In a properly designed system, all dialogs must be initiated with expected duration. This prevents occurance of "zombie" sessions. The fact that Session-Timer is optional and can fail to negotiate makes proper implementation of this difficult. 2. UPDATE without SDP should be exclusively used for session refresh. The fact that UPDATE implementation is optional, produces a lot of issues as well 3. Proxy should be able to terminate the dialog. Without this proxy has no way to handle an invalid data present in the 2XX response and most of the time can only silently observe, even though the call should have been terminated. 4. Parallel proxying is badly broken. It is underspecified, almost never properly implemented and causes multiple issues when anyone attempts to actually use it. This being said, I will try to answer your questions inline On Thu, Jun 11, 2020 at 9:48 PM OKUMURA Shinji wrote: > > First of all, I really think this is a hypothetical problem which has no > good backwards compatible solution. Fixing it will cause more trouble then > leaving it be. > > If you think that my proposal has no good backwards compatible solution, > please point out your concerns more specifically. So we can proceed with > the discussion. > You are proposing a significant proxy behavior change, forcing the proxy to remove Session-Expires from a 2XX response when it is less than Min-SE in the original request. This will cause calls, which were operational (session refreshes more often then Min-SE but not often enough to trigger rate based blocking) to fail. It will also cause a delayed failure with no visible cause to UAC, which is undesirable from the operational standpoint since it makes things hard to troubleshoot. > > Second, I am interested in a document update that targets existing > interop problems with minimal changes to the rest of the document. This > increases the chances of the specification actually being implemented. If > changes are too drastic (even if they make the document clearer and more > readable), there is a much higher chance that implementers will just ignore > the whole update. As far as I am concerned, there are certain things that > make my life easier which I need fixed as quickly as possible. I can accept > things that make other people's lives easier if they do not slow down the > progress of the overall document too much. If something did not cause any > real issues over the past 20 years, as far as I am concerned, it can stay > unchanged. > > We've waited 20 years, so it doesn't matter if it takes a few more > months... > What do you need to fix as quickly as possible? > We need to fix the following: 1. Handling of UPDATE with no SDP glare 2. Handling of UPDATE transactions during initial INVITE These things cause issues when preconditions are used and multiple UPDATE are sent during the initial call setup. We have not used preconditions for the past 20 years and these failures are something that started affecting real deployments for the past couple of years only. This caused the pain level to rise enough so that people decided to update the Session-Timer specification. Realistically, what would be ideal is the document that addresses these issues and nothing else. It would make it easier to point this document to people who face them and offer it as a solution. If the same document fixes 100 other unrelated issues, it would make a lot harder to figure out which changes are required to address the specific problem actually affecting people. The initial plan was to write a separate document which only fixes this specific problem and updates RFC 4028. As we started writing this document, we saw that fixes affect multiple sections of RFC 4028, so the resulting document was becoming very hard to read. So, the consensus was do an RFC 4028 bis, but only change the portions needed to fix this specific problem. Best Regards, _____________ Roman Shpount --0000000000000aa8bf05a7dddc07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

<= div dir=3D"ltr">First of all, we are dealing with a situation where a lot o= f original SIP shortcomings=C2=A0prevent us from developing a good fix. Spe= cifically=C2=A0the following things makes good implementations of session t= imer possible:

1. Session = Timer should have been required. In a properly designed system, all dialogs= must be initiated=C2=A0with expected duration. This prevents occurance=C2= =A0of "zombie" sessions. The fact that Session-Timer is optional = and can fail to negotiate makes proper implementation of this difficult.=C2= =A0

2. UPDATE without SDP = should be exclusively used for session refresh. The fact that UPDATE implem= entation is optional, produces a lot of issues as well

3. Proxy should be able to terminate the dialo= g. Without this proxy has no way to handle an invalid data present in the 2= XX response and most of the time can only silently observe, even though the= call should have been terminated.

4. Parallel proxying is badly broken. It is underspecified, almost= never properly implemented and causes multiple issues when anyone attempts= to actually use it.

This = being said, I will try to answer your questions inline

On Thu, Jun 11= , 2020 at 9:48 PM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
> First of all, I really think this is a hypothe= tical problem which has no good backwards compatible solution. Fixing it wi= ll cause more trouble then leaving it be.

If you think that my proposal has no good backwards compatible solution, pl= ease point out your concerns more specifically. So we can proceed with the = discussion.

You are proposing a signifi= cant proxy behavior change, forcing the proxy to remove Session-Expires fro= m a 2XX response when it is less than Min-SE in the original request. This = will cause calls, which were operational (session refreshes more often then= =C2=A0Min-SE but not often enough to trigger rate based blocking) to fail. = It will also cause a delayed failure with no visible cause to UAC, which is= undesirable from the operational standpoint since it makes things hard to = troubleshoot.
=C2=A0
> Second, I am interested in a document update that targets e= xisting interop problems with minimal changes to the rest of the document. = This increases the chances of the specification actually being implemented.= If changes are too drastic (even if they make the document clearer and mor= e readable), there is a much higher chance that implementers will just igno= re the whole update. As far as I am concerned, there are certain things tha= t make my life easier which I need fixed as quickly as possible. I can acce= pt things that make other people's lives easier if they do not slow dow= n the progress of the overall document too much. If something did not cause= any real issues over the past 20 years, as far as I am concerned, it can s= tay unchanged.

We've waited 20 years, so it doesn't matter if it takes a few more = months...
What do you need to fix as quickly as possible?

We need to fix the following:
1. Handling of UPDATE with= no SDP glare
2. Handling of UPDATE transactions during initial I= NVITE=C2=A0

These things cause issues when precond= itions are used and multiple UPDATE are sent during the initial=C2=A0call s= etup. We have not used preconditions for the past 20 years and these failur= es are something that started affecting real deployments for the past coupl= e of years only. This caused the pain level to rise enough so that people d= ecided to update the Session-Timer specification. Realistically, what would= be ideal is the document that addresses these issues and nothing else. It = would make it easier to point this document to people who face them and off= er it as a solution. If the same document fixes 100 other unrelated issues,= it would make a lot harder to figure out which changes are required to=C2= =A0address the specific problem actually affecting people.

The initial plan was to write a separate document which only fixes= this specific problem and updates RFC 4028. As we started writing this doc= ument, we saw that fixes affect multiple sections of RFC 4028, so the resul= ting document was becoming very hard to read. So, the consensus was do an R= FC 4028 bis, but only change the portions needed to fix this specific probl= em.=C2=A0

Best Regards,
_____________
Roman Shpount<= /div>

=C2=A0
--0000000000000aa8bf05a7dddc07-- From nobody Fri Jun 12 02:08:20 2020 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 E30C73A0E1D for ; Fri, 12 Jun 2020 02:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLOpTPWXfwLr for ; Fri, 12 Jun 2020 02:08:17 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 6B0EB3A0E3A for ; Fri, 12 Jun 2020 02:08:17 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id y18so3506666plr.4 for ; Fri, 12 Jun 2020 02:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9WNZa7H5IbG8Wg9fPKcV2W6zETK1gV4ZkXdPBhuRoSk=; b=aIxFeF4q76+NtV1dvHbcmOBBg8ZfWRvf9rBUBgTCv39qt+gxR+YhLkClx1YyuQPDJC u4Zr1B+wt5N6ZGac7MVWXzMPZhkiRLhXAq0hfnR9ySJw2CsZHL0/51HzHdZ3zndmVPuy NXJXeKYuGFVv4rusQgO7MFH16ZBN3xlfr0iVYaVdEhXpmKH7gILukWoGfqXK28B4cVtY wzy2nLnRh5V6tFwARVKqwc0KMX674/dKgs8NCxMotQUWUiqP29j2/7wMsJj5WMh0Pt2h nJ/BnPHo8A5wV/evOShf4aE2uuapymASjZ1UGZxvbqIwaNmXydPTHfB+cLjFFazg7yRS 2YnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9WNZa7H5IbG8Wg9fPKcV2W6zETK1gV4ZkXdPBhuRoSk=; b=XzoKUqw9jeUGhzETvro01EQi1A/GvhMR4fQBCp+RJeyL1xlVq+2Y4xxpl0jwAONSin UGd6cc4UvNC+HYBps0rIz3fUmrY8i6Cw8tfSyqOMBbcEhshTrWPlf20XQzDsDWShoHc2 rOoY/SiCFmfvKqNWXIZaHNyTlOd+L9rz1NUqpn5ZebH45GQnT6YAbpbnkyzAALxrAy08 /GuP656xVTdqNlU5YG+3sZlMTemDrSFrFZ8+CjFTbKrd2cGJ+B1Sw3UuxZ05L0RpDXYe Bte63Qb8Z6TMB4zOYxPaCB6FYQhnJtw86+jZTCzblE9AAoRO0urwGgvRn0AUeKxUJ65n Rx4g== X-Gm-Message-State: AOAM5306PvWy1c0RqIXOyAYwwcb7wOHYo/1K8bvaHUfZBQCssDD4xX/K wJM+VleP8GSP0ZTEGxitxTuYTfHu X-Google-Smtp-Source: ABdhPJzutqCbZC4eAwDekqzx2KUhQx3exTCv6d4WhCzy1dIEOKvYB5MGVPfo0NsDCCuvxFulsUWW7g== X-Received: by 2002:a17:90a:1781:: with SMTP id q1mr11459200pja.24.1591952896574; Fri, 12 Jun 2020 02:08:16 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id d22sm4891313pgh.64.2020.06.12.02.08.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 02:08:16 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Roman Shpount , Paul Kyzivat References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> Message-ID: <49aa044d-89f6-5b81-4f32-ff509feef598@gmail.com> Date: Fri, 12 Jun 2020 18:08:12 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 09:08:19 -0000 Roman, Your E-Mail is so diverse, so I will reply to a part of them. >> First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be. > >If you think that my proposal has no good backwards compatible solution, please point out your concerns more specifically. So we can proceed with the discussion. > > You are proposing a significant proxy behavior change, forcing the proxy to remove Session-Expires from a 2XX response when it is less than Min-SE in the original request. This will cause calls, which were operational (session refreshes more often then Min-SE but not often enough to trigger rate based blocking) to fail. It will also cause a delayed failure with no visible cause to UAC, which is undesirable from the operational standpoint since it makes things hard to troubleshoot. At 1st, I didn't suggest that the proxy should remove SE from 2xx. I suggested that the proxy should increase SE-value greater than Min-SE in the original request. In the first place, the response of UAS is against the rules, so the problem is not that the connection fails, but that the connection succeeds with incorrect parameters. If proxy increases SE-value to a reasonable level, the UAC can refresh the session with a reasonable frequency. This is it for now. Regards, Shinji On 2020/06/12 16:16, Roman Shpount wrote: > Shinji, > > First of all, we are dealing with a situation where a lot of original SIP shortcomings prevent us from developing a good fix. Specifically the following things makes good implementations of session timer possible: > > 1. Session Timer should have been required. In a properly designed system, all dialogs must be initiated with expected duration. This prevents occurance of "zombie" sessions. The fact that Session-Timer is optional and can fail to negotiate makes proper implementation of this difficult. > > 2. UPDATE without SDP should be exclusively used for session refresh. The fact that UPDATE implementation is optional, produces a lot of issues as well > > 3. Proxy should be able to terminate the dialog. Without this proxy has no way to handle an invalid data present in the 2XX response and most of the time can only silently observe, even though the call should have been terminated. > > 4. Parallel proxying is badly broken. It is underspecified, almost never properly implemented and causes multiple issues when anyone attempts to actually use it. > > This being said, I will try to answer your questions inline > > On Thu, Jun 11, 2020 at 9:48 PM OKUMURA Shinji > wrote: > > > First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be. > > If you think that my proposal has no good backwards compatible solution, please point out your concerns more specifically. So we can proceed with the discussion. > > > You are proposing a significant proxy behavior change, forcing the proxy to remove Session-Expires from a 2XX response when it is less than Min-SE in the original request. This will cause calls, which were operational (session refreshes more often then Min-SE but not often enough to trigger rate based blocking) to fail. It will also cause a delayed failure with no visible cause to UAC, which is undesirable from the operational standpoint since it makes things hard to troubleshoot. > > > Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged. > > We've waited 20 years, so it doesn't matter if it takes a few more months... > What do you need to fix as quickly as possible? > > > We need to fix the following: > 1. Handling of UPDATE with no SDP glare > 2. Handling of UPDATE transactions during initial INVITE > > These things cause issues when preconditions are used and multiple UPDATE are sent during the initial call setup. We have not used preconditions for the past 20 years and these failures are something that started affecting real deployments for the past couple of years only. This caused the pain level to rise enough so that people decided to update the Session-Timer specification. Realistically, what would be ideal is the document that addresses these issues and nothing else. It would make it easier to point this document to people who face them and offer it as a solution. If the same document fixes 100 other unrelated issues, it would make a lot harder to figure out which changes are required to address the specific problem actually affecting people. > > The initial plan was to write a separate document which only fixes this specific problem and updates RFC 4028. As we started writing this document, we saw that fixes affect multiple sections of RFC 4028, so the resulting document was becoming very hard to read. So, the consensus was do an RFC 4028 bis, but only change the portions needed to fix this specific problem. > > Best Regards, > _____________ > Roman Shpount > From nobody Fri Jun 12 09:03:19 2020 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 289113A0C75 for ; Fri, 12 Jun 2020 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW11yLG0lEP1 for ; Fri, 12 Jun 2020 09:03:15 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 7CE913A0946 for ; Fri, 12 Jun 2020 09:03:15 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id y17so3912624plb.8 for ; Fri, 12 Jun 2020 09:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UYx8up/dSrWRp8wEd0UXO6Z62Iqry6ID7S3S2lBJY8s=; b=H+IgC0k1g41Ws8KVMfluh2BKyoGMT13NWdmvxZCA4gRrkZLljloDNKOvZOng/dv20x jUqcWODqzSxWeUjJNWNqhTOK8VqOJ0YfpLXBfXoAPZAZ8URJVkBTiUFcvNYuGlEFl1aB mZVRGiWdosqBJj7pUJCUwGoCYwqz180dUR/uqG0u7OmS0q7kBMmJuo7rnJMpKo62YyV4 HNIns5tpFdRGPfQv5qwldpY3xCEMfKo4cCGPmHDCRmDIUFQqGKGMaNeu6vcv3u3/450N YJl1iTEpuouozaM/gYWwJBqn8fAX4q8uEqyVrI8YRa5jDAcr1zYobg1pHZLU1BGSqAjY pLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UYx8up/dSrWRp8wEd0UXO6Z62Iqry6ID7S3S2lBJY8s=; b=KH5HYraEvglvqyzgyYfCEZDW3ngW7OkPFkM0sr+jIjT7HhdqSLeCVlGM7AmYP7Telv 3HIaVhlbC3k32tIurdPbNuACmu9KyjsBJH6rrdrfg4ak4z9VitFVdpCEWV65mmdCz3Ha H3awsVMmqzHa33j3TeddYT0HkSXMXwvGjrW2m2Qug91UlF62vAoARGV5tMC5wI1m4i/3 5zW52iq28Rf9lvsckUyXYKXKD2aAyhzTcznfUHQZnN0xV/ZI2vVjyqngaya/BMzbC/Pb VTDEeunzewLN97Le7KeQziFMGcdnoBb/QEvb+xV9CrGgp2qcRlMxbe1BSyNsuoG9WX0W HwwQ== X-Gm-Message-State: AOAM533mkIiJGp+mEEOwBmHzwdylH4cCpF4STVbDgoxbyvtRCiakzwnA BlChzO/7p9kQ8lgS4Y3lUSYd+G/7 X-Google-Smtp-Source: ABdhPJyRooJeuYKhTE9BiM0FDygynXUctHWmceWN9uflj+vBPP5eZSKRsFfa3z/4QMyeck02/fAabg== X-Received: by 2002:a17:90b:4d10:: with SMTP id mw16mr13412360pjb.143.1591977793974; Fri, 12 Jun 2020 09:03:13 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id a17sm6575158pfi.203.2020.06.12.09.03.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 09:03:13 -0700 (PDT) To: SIPCORE Cc: Roman Shpount , Paul Kyzivat References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> From: OKUMURA Shinji Message-ID: Date: Sat, 13 Jun 2020 01:03:10 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200612-2, 2020/06/12), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:03:17 -0000 Hi, On 2020/06/12 16:16, Roman Shpount wrote: >> What do you need to fix as quickly as possible? > > We need to fix the following: > 1. Handling of UPDATE with no SDP glare Specifically what is this issue? > 2. Handling of UPDATE transactions during initial INVITE I think the simplest solution is that SE and MSE headers should be ignored during early dialog. Because with respect to a session-timer, 2xx response is the only answer to an initial INVITE. Regards, Shinji From nobody Fri Jun 12 09:53:23 2020 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 EB1393A118C for ; Fri, 12 Jun 2020 09:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 nZibRkcJBvJ4 for ; Fri, 12 Jun 2020 09:53:21 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (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 65B9D3A0F02 for ; Fri, 12 Jun 2020 09:53:21 -0700 (PDT) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id A669D402D2 for ; Fri, 12 Jun 2020 16:53:20 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=ZOkhvkb6LifnexDw7zYIC02xeO2YYMp9JkT53X7CZSw=; b=Nys43suCbAQgFbFBqV/S3sJ8G+uh/yNUZlo7GqG+pj1MbOj0TVeLJGZC7/xYykS3PRqSiSQzc+tZ8sL7k0lFdsY4KBijI+YJdWAKXE2qnt4YtlbAhElMO3b1gd675XZCtSeDz0No5wEoWlZ/WFSmBbSlx8XnlksLT2kWMbvAfCDPjwKQ6k6usbKGeiG5p6AebJUbD5Gxt/rQm7LYYbY1iaADYrkNpftsGC1vxxaaS4MdWQQzpOcMCFbCQf2l3re9WEl7a1HtSOiMcGWQ/AX7uJLIR5dHsXy/X9PN7jlpwO5yi+jd7peQZPVfgTAAzieXVp9hYbW040JOKvcSourOmg== Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Fri, 12 Jun 2020 16:53:19 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 48) id EA47C802A5B; Fri, 12 Jun 2020 16:53:19 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 12 Jun 2020 22:53:19 +0600 To: "OKUMURA Shinji" , "SIPCORE" Cc: "Roman Shpount" From: "Samir Srivastava" In-Reply-To: References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> Content-Type: multipart/alternative; boundary="=_e7cdb34baf897152d99fef60057a1a43" Message-Id: <20200612165319.EA47C802A5B@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:53:23 -0000 --=_e7cdb34baf897152d99fef60057a1a43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, in-line below. ThanksSamir On 6/12/2020 at 9:33 PM, "OKUMURA Shinji" wrote:Hi, On 2020/06/12 16:16, Roman Shpount wrote: >> What do you need to fix as quickly as possible? > > We need to fix the following: > 1. Handling of UPDATE with no SDP glare Specifically what is this issue? > 2. Handling of UPDATE transactions during initial INVITE I think the simplest solution is that SE and MSE headers should be ignored during early dialog. Because with respect to a session-timer, 2xx response is the only answer to an initial INVITE. SS>> SE and MSE cannot be ignored in early dialog. Early dialog can be spanned over for 30 minutes or so. It can be larger than hour. Long time to get final answer. Yr wait time is dependent on the rush hour or so. Regards, Shinji _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --=_e7cdb34baf897152d99fef60057a1a43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,=
  in-line below.

Thanks
Samir<= br>
On 6/12/2020 at 9:33 PM, "OKUMURA Shinji" <ietf.shinji@gmail.com&= gt; wrote:
Hi,

On 2020/06/12 16:16, Roman Shpount wrote:>> What do you need to fix as quickly as possible?
>
> = We need to fix the following:
> 1. Handling of UPDATE with no SDP gla= re

Specifically what is this issue?

> 2. Handling of UPDAT= E transactions during initial INVITE

I think the simplest solution i= s that SE and MSE headers should be ignored during early dialog. Because wi= th respect to a session-timer, 2xx response is the only answer to an initia= l INVITE.

SS>> SE and MSE cannot be ignored in early dialog. E= arly dialog can be spanned over for 30 minutes or so. It can be larger than= hour.  Long time to get final answer. Yr wait time is dependent on th= e rush hour or so.

Regards,
Shinji

_______________________= ________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org= /mailman/listinfo/sipcore
 --=_e7cdb34baf897152d99fef60057a1a43-- From nobody Fri Jun 12 10:38:16 2020 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 C61153A1204 for ; Fri, 12 Jun 2020 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 ZeHHaSnnW_TN for ; Fri, 12 Jun 2020 10:38:14 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::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 EDC223A1200 for ; Fri, 12 Jun 2020 10:38:13 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id s21so9399794oic.9 for ; Fri, 12 Jun 2020 10:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z9/TTU1yjxWbhLATf2esGCC6DVm8mSaRjLEOj3GOSFw=; b=bX5bM0xM3dF6jWnEXhXo97F6+p/0LDeDX/iRsI64QBqmPlYKjaKrRuOdoUSCfphqqC bTVlr/D+e0ThW1VJ00gfElW8BcEBDSHExeo8/6feD0HE9qF3mHaipqGlyGN+p5ARfx1s 9+TvptWHA/uNmLLIA4AIu9uwPhgWsv1QmBlWQAP+QR3aP3CRa1q4Cyhlr/1BGgy8IuV6 s3CvDqBm2pN96eT3Y4aJyKWhCJJ6KAeY3G+Nz9DUXeSzY9a7bTijPlMREuQFGklt8Zxt ImTiN238RIDFeMTVIVFeOVKnklUE2Kc5BmV/hX81eW8Q/1z8XrrsjPvByX69BPGaBvvp f7uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z9/TTU1yjxWbhLATf2esGCC6DVm8mSaRjLEOj3GOSFw=; b=q5/IOK6wDtC1eMAXTA2ywKePkS2CkpFJchkjum5nmcnCA2oIlGA/duFjy0GpRpLvCr 1qow4rIcP9mMd/IPM0N+tVaxuBbRqCAaMDP86grhIMYzu+W9jXJ1I3Q4VxaES/bqFsGT INmV4f7DhSLfDDTGIv+4oK6+RNX01OCRcYFWvGwswrGdBcmAIxye1TAofl9lU9kzWmG1 UUEZ3ek6Wwi35bjHr7fjY0Hal6Jr/9b/l8292hM6svhG9uuDP7HxKBq2CUqR1jhtSbel 1kN9/XmA6JPgC14LkdRBDxO0IP3OVW42F57cY3whSj9NlC5kHuYW1A/DdNNjA3rhissz +Nig== X-Gm-Message-State: AOAM532Gk8DuZbtHmK/kMkqu5xsV8aZy4VGbtyTisQtG6b4A1OkaMH1x g03htUq2+JB3uYIHYV2XCKkeh9JSQa8= X-Google-Smtp-Source: ABdhPJw5jUfjyFQ0b9IssUfixh5R5Tmgq7Du/JofKoTqUFkw4xd17CwkQQgGm0ohUL7BYCZsD0i41Q== X-Received: by 2002:aca:304b:: with SMTP id w72mr41323oiw.122.1591983492792; Fri, 12 Jun 2020 10:38:12 -0700 (PDT) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com. [209.85.167.179]) by smtp.gmail.com with ESMTPSA id y197sm1477444oie.58.2020.06.12.10.38.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 10:38:11 -0700 (PDT) Received: by mail-oi1-f179.google.com with SMTP id b8so9454614oic.1 for ; Fri, 12 Jun 2020 10:38:11 -0700 (PDT) X-Received: by 2002:aca:72c2:: with SMTP id p185mr9053oic.139.1591983491191; Fri, 12 Jun 2020 10:38:11 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> In-Reply-To: From: Roman Shpount Date: Fri, 12 Jun 2020 13:37:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , Paul Kyzivat Content-Type: multipart/alternative; boundary="0000000000007b1b4905a7e68aaa" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 17:38:16 -0000 --0000000000007b1b4905a7e68aaa Content-Type: text/plain; charset="UTF-8" On Fri, Jun 12, 2020 at 12:03 PM OKUMURA Shinji wrote: > On 2020/06/12 16:16, Roman Shpount wrote: > > 1. Handling of UPDATE with no SDP glare > > Specifically what is this issue? > If both UA send the UPDATE with no SDP, according to the current specification it is not considered glare and 491 response is not sent. If both UPDATE transactions change session timer parameters, such as refresher at the same time, then the negotiated result can be ambiguous. Best solution would be to force the 491 response if two UPDATE without SDP contain session timer parameters. > 2. Handling of UPDATE transactions during initial INVITE > > I think the simplest solution is that SE and MSE headers should be ignored > during early dialog. Because with respect to a session-timer, 2xx response > is the only answer to an initial INVITE. > This is not that simple. You can have an UPDATE transaction which starts before 2XX for the INVITE transaction is sent with 2XX response for UPDATE arriving before or after 2XX for the INVITE depending on the network paths or network delays. If different session timer parameters were used for UPDATE and INVITE, the negotiated session timer is ambiguous. Also, the definition of during the INVITE transaction is ambiguous as well. Due to network delays, it will be different for UAC, UAS and proxies in the path. Another question was when does the session timer start? Is it from the time that the INVITE/UPDATE message was sent or was it from the time 2XX response was received. I am not actually looking for answers in this thread. I am just letting you know what issues I need resolved. This group actually spent a considerable amount of time discussing the solutions for all of this, so the best option would be to restart the discussion for each of those issues in a separate thread with a quick recap of what was already discussed. Thank You, _____________ Roman Shpount --0000000000007b1b4905a7e68aaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 12, 2020 at 12:03 PM OKUMURA = Shinji <ietf.= shinji@gmail.com> wrote:
On 2020/06/12 16:16, Roman Shpou= nt wrote:
> 1. Handling of UPDATE with no SDP glare

Specifically what is this issue?
=C2=A0
If b= oth UA send the UPDATE with no SDP, according to the current specification = it is not considered glare and 491 response is not sent. If both UPDATE tra= nsactions change session timer parameters, such as refresher at the same ti= me, then the negotiated result can be ambiguous. Best solution would be to = force the 491 response if two UPDATE without SDP contain session timer para= meters.

> 2. Handling of UPDATE transactions during initial INVITE

I think the simplest solution is that SE and MSE headers should be ignored = during early dialog. Because with respect to a session-timer, 2xx response = is the only answer to an initial INVITE.

This is not that simple.

You can have an UPDATE = transaction which starts before 2XX for the INVITE transaction is sent with= 2XX response for UPDATE arriving before or after 2XX for the INVITE depend= ing on the network paths or network delays. If different session timer=C2= =A0parameters were used for UPDATE and INVITE, the negotiated session timer= is ambiguous. Also, the definition of during the INVITE transaction is amb= iguous=C2=A0as well. Due to network delays, it will be different for UAC, U= AS and proxies in the path.

Another question was w= hen does the session timer start? Is it from the time that the INVITE/UPDAT= E message was sent or was it from the time 2XX response was received.
=

I am not actually looking for answers in this thread. = I am just letting you know what issues I need resolved. This group actually= spent a considerable amount of time discussing the solutions for all of th= is, so the best option would be to restart the discussion for each of those= issues in a separate thread with a quick recap of what was already discuss= ed.

Thank You,
____= _________
Roman Shpount=C2=A0
--0000000000007b1b4905a7e68aaa-- From nobody Fri Jun 12 14:54:53 2020 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 29C343A092A for ; Fri, 12 Jun 2020 14:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 80MiaGjCKNpm for ; Fri, 12 Jun 2020 14:54:50 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640109.outbound.protection.outlook.com [40.107.64.109]) (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 BA97E3A0925 for ; Fri, 12 Jun 2020 14:54:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jsfMIGE/dWIJ+jdZttuKwIdjfHPwlYveLxHjRkK4nkgYboWjN1yzx6Wv7EjU2Eqxi0ZmFKu5lDl9pWq8lkPDw3+CWS4YFotnkkS+9V0o5dZ1lBGZcAqtwJTcqgaqjlXx4zEdHu7+NEMFvAUxb15U3BZuTfOhoSCY4OIljPkHk2lOKNG6CSqMV8QxjW00gqY0GW+SS5UBf9SHirtKvzDmAJzx+kxGlUtOtczrxn9nGDvlaQJ9EpOpLwJrZ4sCcJ6wkVZKYBgtmWnsP5QYrJDZm+MA2RvDCFEY8IIifcDGwm1LRcJQUtpUXRugk0yd3YlaDtn4thEuwSDh+uP1kta77w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HVf9FSpt0DrrCtfN089KgRlWh0E7xSQuseAQgFbOy3w=; b=OBvbQMlKpzHQnfkEXYy7uH4+1U3+OF45dS0i8blc23Rl4FvYTcyThdMrqIt15Dj+5GOafBY6vEH7SHbAZU/ddsnTfQGeFovm3SZkb5ixVSa4QhLLeDbs0bAtPvuz7AZ9mNN6ZUlVS0LThN5DGSPsCGJ23743H+YkpmW0D7P+lQ48aEgSACkP21TFnqkfQCT4dzc3/AnG0h8ZwJkG5Wj2lWjrBpfNFGhtJ1opc7Umfv0cu7o7qkzxu6obfW4l6K9bYWKumOsH10Ax8fsIdvnXNZG4Val/IJbyyBZkm9L0joqbOwnI3vNlvoi3m91ImzcvavbRPzZ1u0tjXnXWkBFDNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HVf9FSpt0DrrCtfN089KgRlWh0E7xSQuseAQgFbOy3w=; b=gw2G/d6ni2c/4Rr0qHuXfPw9oVbhSCACScEvmE5p6Q0HAHI9MVnHyh1dMl/AtfdMakw8mH2Coa0Z3JkVsoc6Ylat0WdgGzZfluILBlt8Ky3juIrB+HmmVqi8glZ+G86A0tnyRW0Sz3RXPeHslbFh3HXMy6HGE0Z9UEYE5I6PXDc= Received: from MW2PR00MB0425.namprd00.prod.outlook.com (2603:10b6:302:b::13) by CO2PR00MB0168.namprd00.prod.outlook.com (2603:10b6:102:15::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3133.0; Fri, 12 Jun 2020 21:54:48 +0000 Received: from MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1]) by MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1%5]) with mapi id 15.20.3136.000; Fri, 12 Jun 2020 21:54:48 +0000 From: Russ Penar To: "sipcore@ietf.org" Thread-Topic: please review and comment on draft-penar-ietf-sipcore Thread-Index: AdZBBAfA3uPUg+ERQ5G4Wnos9BXr1w== Date: Fri, 12 Jun 2020 21:54:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6de2e19-785d-403b-9c7e-00006df9e7a1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T21:51:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 15d3b433-b090-41b1-022d-08d80f1b3a35 x-ms-traffictypediagnostic: CO2PR00MB0168: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SyJA2b92Hy+1jztKj7TPTOIKKAxoW2d2tj56Ii5DqA41LMKJfzVCmI8WauVI3OVP0mSncSN/y2d1c7LXvnBRhM6oEm+Gy3DUqX2+ClztXYiG8uhoBF3QIzOVMtCdynAI1YeHhw64xO7MZo14SqIg/QJcLvGZAX/lr/xZmGB5HQ5KcI7kA23TDWtYz5mhOFUfLxM0qdateqHdxhARzSet8zamB6ssZt/hNpxzLxHr1uGXrvMswgPY5SpCkfd/JAknRdLE8LnH3+VEQne1RxI8iLhrqa/JiANLuao2ZwQD+lWwH7kEbLBujUE0ubkCjWGPkalmxDsQitdv3UmU5u+/XJ/jQG2OR/HveHVtuWjOfQx38tPX9ZfivZWIpAERTktSmDUJDF1jTrL13P0zHAPuNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0425.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(136003)(396003)(39860400002)(66446008)(64756008)(66556008)(66476007)(166002)(6506007)(76116006)(71200400001)(66946007)(52536014)(5660300002)(82950400001)(7696005)(478600001)(82960400001)(83380400001)(966005)(10290500003)(26005)(55016002)(6916009)(86362001)(9686003)(8676002)(316002)(8990500004)(9326002)(186003)(33656002)(2906002)(8936002)(4744005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KOtC8W0qqRPaycf85/ssQ22TWI7+B/8fybuqOICMlYAgVFVe7fPb3iCYFqpoeiYny/iTKnMiR3ABgs+ZnE0m4NOEUr8Gw6TpiLRhIakn9BBcdu32akpA1phsXSEHkHF17LZAuVFDcVBIdZqN5EJ6/qzauD1z/7CsL8N3yrKMXU+uAhZxUgu9+M3e+XHYxJMYgb9VlDHJgLZVnJvoOelFRyoXmQ/E0JLMbviNG088o0/mVXLchdyC92TbF8PLhxVLU/T/N4o6qdatycAeXc1rexqJXww4SK++AFzMHqkVeyMNNbprdO2ro5/3z3V7xPSESGPjYEMWJdUUuP6dwYNP+BCi9ZrHkGbgeHf1l/vXvTFTQTS+jse1m0Vai2hWqHIwx19FArDT2OYU5jrBrF0m1ZLL7svSRQH9KCeYSZCHNpR6rRY+mfk2rAHQdQLgJvNaV6au32E0df9cpxVkKRMrts01MWzFiJLW2WLluyW7X88= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0425DAA48EB66C5C03245AEEB6810MW2PR00MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0425.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15d3b433-b090-41b1-022d-08d80f1b3a35 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 21:54:48.6841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3ZJQ/6Xb9d0Un8rVC6kF6dzPYmo3zJ/0ddxjrZW8N0IsIZjcKyCtzk2E5VPgeDmuDIptxLd2CoJKTPVxUTO7IQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0168 Archived-At: Subject: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 21:54:52 -0000 --_000_MW2PR00MB0425DAA48EB66C5C03245AEEB6810MW2PR00MB0425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please take a look at my proposed draft regarding a 1xx message letting cal= ler know their call is rated poorly/ambiguously. One early feedback is 184 may be too close to progress messages associated = with ringback, and I'd love to get more perspectives. https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ Best regards, Russ --_000_MW2PR00MB0425DAA48EB66C5C03245AEEB6810MW2PR00MB0425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Please take a look at my= proposed draft regarding a 1xx message letting caller know their call is r= ated poorly/ambiguously.

One early feedback is 18= 4 may be too close to progress messages associated with ringback, and IR= 17;d love to get more perspectives.

https://datatracker.ietf.org= /doc/draft-penar-ietf-sipcore/

Best regards,

Russ

--_000_MW2PR00MB0425DAA48EB66C5C03245AEEB6810MW2PR00MB0425namp_-- From nobody Fri Jun 12 17:01:38 2020 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 EE6773A165F for ; Fri, 12 Jun 2020 17:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 1pm_xmWQOCG5 for ; Fri, 12 Jun 2020 17:01:34 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650126.outbound.protection.outlook.com [40.107.65.126]) (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 109CC3A0A32 for ; Fri, 12 Jun 2020 17:01:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rh4/E0537jNFqJmJ5qcUMdjLkS2Rfjpe+A67daDCq47rJa85t58dHdnzl41eT2kU9PUpDi0FiFEiBVJmDt/0IvY7cfEF6zFCwZD5EPzdk5xpxdCVso/xgssYOX6bwbNAXj6HNKkGYClaq3OEB8lA2rfUMNpgfQXRYFI43e3e6oxPHWMC+fykr3IOrmjZEHO7DKrljBE8Rnq4gRkgBFCE+PDSCkBR/ReEpuLQMXaApg/AKRI/we6J7XsyEDqfPO2QOvMGv2Pqm8du7O1+tz9VPDtSu5sefVF036yvA+GySVTBL0TfDV7aCRqXZvLcALiigoXXFe8TDInvobDafWveZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6j3OiOfEEAZZ3ZuXbg2OMc/4fL6Q+cSwtPmg2BRDY+s=; b=jjQtIXuFUrTKkQTF20tNjQHVknxhO35DQ1+D7AQwCophVEXWDniPLzZye8FE81Wvh4F9HKwYtTlgmEpUpPb4cinA/WoqubnGTPuHsidHdhrxiBNm0+vsDYWWAPiTV30hu3hfNPY3d3h6DJ2bu/i4XI5qpPPHe/dsilEFvHeNxSbwAJkGnSsNiHOYBjQuoCMiZEBv0klDMY0/MCrhYtCfhRRrskuYKmmoclBmCZS7KTPPOOcdLQx1UZPYBdPkJRxZowHtuFKrPJPfn3rd6vmqzqD938+FMBHxc7QY0gEyzoY0IcbsvmhaWjOCG4UGfF1HuuN4iE2cgvJdnRx5FoDQBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6j3OiOfEEAZZ3ZuXbg2OMc/4fL6Q+cSwtPmg2BRDY+s=; b=H3b/bmt0YThyehlN7l27q2oAT/neTog9j1mXqj2KoU+0cmJMSVZrxON7zamktnpdafiLXaXlb23rDZEF0nrHW6kFL7NzxMzKMrUE0FjTwrv6G7D7aMTzhQJH/ztfZYf3IdFLKDrMeviCBCPZqz8yfOZEK9Ho2X05YM7mTlU2U4I= Received: from MW2PR00MB0425.namprd00.prod.outlook.com (2603:10b6:302:b::13) by CO2PR00MB0134.namprd00.prod.outlook.com (2603:10b6:102:18::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3135.0; Sat, 13 Jun 2020 00:01:32 +0000 Received: from MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1]) by MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1%5]) with mapi id 15.20.3136.000; Sat, 13 Jun 2020 00:01:32 +0000 From: Russ Penar To: "sipcore@ietf.org" Thread-Topic: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AdZBFbmIYErjvgZESFeR9rthnkycuw== Date: Sat, 13 Jun 2020 00:01:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6de2e19-785d-403b-9c7e-00006df9e7a1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T21:51:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5289657f-34e2-46f2-147f-08d80f2cee13 x-ms-traffictypediagnostic: CO2PR00MB0134: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0433DB2766 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VHhqCyVedRJgpuvnTyUVI4Cxx/zR73rR08VTTdm981yUewCkRYerXthWRj4KJv4aogiiTDI5z3GKykPOtkADVYQQg96rw7twB0QL8F/mkcGE5ZjT/K90IfQzCQ/IbdoDfuFsOEbptOkYZSzDaxKDbB6HBl8dX9YxpEMJQgLyUuI8990PIWU2Gr+0zAVggT4pR9WYparl6i6Ao4SMv0hHiMzmechvcSuGQ9xiijU454K5nYcmCZUuc8W15uCdk+J90zUftKQgRN9W+bDyw0NXtPCR6aSf0o6jBinUE84Ryl+3sjo19427hoJpfCd7RhjnzhITAsZlGRjIrOyx9i+nfThyJIfezgrgcyarBVlNhHISI+d5DVAmvkbK81dxN+2zShpGxUXkPeu+uiOUj9C/2A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0425.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(366004)(396003)(26005)(186003)(8936002)(8676002)(53546011)(6506007)(52536014)(8990500004)(7696005)(966005)(6916009)(2906002)(71200400001)(83380400001)(33656002)(55016002)(316002)(82960400001)(86362001)(5660300002)(82950400001)(66946007)(76116006)(66446008)(64756008)(66476007)(4744005)(9686003)(66556008)(478600001)(10290500003)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Qy+T19xSjUN4ZfojnfcCWFKNcLG6O5w2TBWN0kevgRUOtpeX8Yma85+xEAWbKRNaUTlk9NqIw+i7skzMjXadNVQSP59bkcAqxsEnjbJq65eyUmjIUylrV34a7GUy8tz3bVy8XMN0WUeT/A4j/7Q7FCLAmBm+E4AjKQ2ZbP4ZoDD4+uXl1tlQTji8JRSBwxBydDb3tFW3w5+ISaLBtU4WOmLcTT+8Cwe3vcaGpBgfvDhhir0LlXrvLsoZt1+sfSTjGBy0uBHGbJYnq3wsbqqe/cC3bXr9broB0FdiFPL/wqA93QrJcvk4iHpKTBJlA4eloeijx09O/VQOf8sCjq/LCmgKQL8nLmR84kZg3xxdBmtbNfdEKDHOjMvZ9QKIur/bh+aCusVx/5NcsnHyfj9qMb8ng12mnjRPslMZudnt8IoZ+1EEgzRDSefBYqcfQyG3P5/nDwKiDc+dhkA5gZ8bxHiapXDqCNAYdGhn0XkHMJ0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0425FE84CF9EA717A7B76180B69E0MW2PR00MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0425.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5289657f-34e2-46f2-147f-08d80f2cee13 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 00:01:31.8581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DC347ve/TkmALR3xVBn3TNdKk4luh9/z8eo96Df8Zez9e9pIdvwUi/zE7K9hMQjLoXTWo6zQZ2mI20sB6/vwvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0134 Archived-At: Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 00:01:36 -0000 --_000_MW2PR00MB0425FE84CF9EA717A7B76180B69E0MW2PR00MB0425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on early feedback, I updated the name and proposed code number. Please review the newly named draft, I welcome everyone's perspective, than= k you! https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ From: Russ Penar Sent: Friday, June 12, 2020 2:55 PM To: 'sipcore@ietf.org' Subject: please review and comment on draft-penar-ietf-sipcore Hi All, Please take a look at my proposed draft regarding a 1xx message letting cal= ler know their call is rated poorly/ambiguously. One early feedback is 184 may be too close to progress messages associated = with ringback, and I'd love to get more perspectives. https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ Best regards, Russ --_000_MW2PR00MB0425FE84CF9EA717A7B76180B69E0MW2PR00MB0425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on early feedback, I updated the name and prop= osed code number.

Please review the newly named draft, I welcome every= one’s perspective, thank you!

 

https://datatracker.ietf.org/doc/draft-penar-s= ipcore-ratingprovided/

 

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: 'sipcore@ietf.org' <sipcore@ietf.org>
Subject: please review and comment on draft-penar-ietf-sipcore<= /o:p>

 

Hi All,

Please take a look at my= proposed draft regarding a 1xx message letting caller know their call is r= ated poorly/ambiguously.

One early feedback is 18= 4 may be too close to progress messages associated with ringback, and IR= 17;d love to get more perspectives.

https://datatracker.ietf.org= /doc/draft-penar-ietf-sipcore/

Best regards,

Russ

--_000_MW2PR00MB0425FE84CF9EA717A7B76180B69E0MW2PR00MB0425namp_-- From nobody Fri Jun 12 20:16:10 2020 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 007423A07AA for ; Fri, 12 Jun 2020 20:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g7viSw5GEy3 for ; Fri, 12 Jun 2020 20:16:07 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 C63E43A07A6 for ; Fri, 12 Jun 2020 20:16:07 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id i4so4669835pjd.0 for ; Fri, 12 Jun 2020 20:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Uc1gbKqXkFKO2+oo1Kr+i5sYz/zAAbnEAfsY3QsgY00=; b=Ar61Xh++eqeI2SKNFY7w0vOqcX56wxNSQ4G3rp+ie8v28HLeaBl/6Rh2/9f1HFlO68 6qz7lIvSGp2pHo2Jzqj9/WPzDVnl0dCdPjOcD2+P17O/dNxHrZXUxNhX3BIW5G7oNECq fL4Zws5yxsw4obHcvmZ1R/HGjzld/BnGy/jhJatgtunzK6yeuosYy2QhAOv56S17VV4Y EMhUVSOukWt9oWsV7VlDEDFYL+q9maaueZWT4aRSYtKCBEDLKlHg+AtX2tO5GHFYuqCT Kl2eB4Su3oLVgRx50HfZwFBpwluXSk6N0WJX1OW9i00EQbfxWJ7VkkKNfRvuyvon7acv FcSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Uc1gbKqXkFKO2+oo1Kr+i5sYz/zAAbnEAfsY3QsgY00=; b=lPPd4ChoxGsVEUfdzuRq0cqIpfciySBBpfMbf0J+VU2ZMDJqc3RT35IxhpFWqaCrKF 0vE55qwVhknFRdJxy/SDEtyC9qtIBGOF21NWYdPFv6KzFlc4X2UK19xyoci1icqRrvGQ yqmPcXyKst2hOW9wP2uen8Vxgas366CGs6r5RC4RxtTjFE5L1xBk0p7SmEohBqrzEMNg l/hI4UeTIlp73iRYpWyFe0MPU5EFu5XPOcdnKgZwoZy1x/61ip0HPxhI70NzqR7kMmg9 gZoxphKq7c/S3NulUI5PmuIcQW9GSgea2dvA5NQF9KjA9rCECZlnWzRNFBRpFXGghZj7 tU8w== X-Gm-Message-State: AOAM53240bBEHxPhHPuetVNf7V9E+ymp7YJy6t/CqyKNy46GGDf3B61z WGJvAzk9YDfB8xTryPjRrjk= X-Google-Smtp-Source: ABdhPJwXmc8Dt/1H9ZwuUCBye8p4SLopTQDrWiAPlBJzDBpOiq1n4hR25ybVD87/CRluk1ZR50f0gQ== X-Received: by 2002:a17:902:c408:: with SMTP id k8mr14236648plk.279.1592018167086; Fri, 12 Jun 2020 20:16:07 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id r20sm7803245pfc.101.2020.06.12.20.16.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 20:16:06 -0700 (PDT) To: SIPCORE Cc: Samir Srivastava , Roman Shpount References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <20200612165319.EA47C802A5B@smtp.hushmail.com> From: OKUMURA Shinji Message-ID: Date: Sat, 13 Jun 2020 12:16:01 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612165319.EA47C802A5B@smtp.hushmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200612-2, 2020/06/12), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 03:16:09 -0000 Hi, I don't doubt that a session-timer starts when the 2xx response is received. I think this is another item that should be clarified. So I don't think it's a problem if the early dialog has a longer duration. And the validity of early dialogs depends on the Expires header in an initial INVITE request, doesn't it? Regards, Shinji On 2020/06/13 1:53, Samir Srivastava wrote: > Hi, in-line below. > ThanksSamir > > On 6/12/2020 at 9:33 PM, "OKUMURA Shinji" wrote:Hi, > > On 2020/06/12 16:16, Roman Shpount wrote: >>> What do you need to fix as quickly as possible? >> >> We need to fix the following: >> 1. Handling of UPDATE with no SDP glare > > Specifically what is this issue? > >> 2. Handling of UPDATE transactions during initial INVITE > > I think the simplest solution is that SE and MSE headers should be > ignored during early dialog. Because with respect to a session-timer, > 2xx response is the only answer to an initial INVITE. > > SS>> SE and MSE cannot be ignored in early dialog. Early dialog can be > spanned over for 30 minutes or so. It can be larger than hour. Long > time to get final answer. Yr wait time is dependent on the rush hour > or so. > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Jun 13 02:05:17 2020 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 78AA23A0AB8 for ; Sat, 13 Jun 2020 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OikI0F2lkV6 for ; Sat, 13 Jun 2020 02:05:14 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 3E3AE3A0AB5 for ; Sat, 13 Jun 2020 02:05:14 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id x11so4719927plv.9 for ; Sat, 13 Jun 2020 02:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W9pn5ZLXOPcONTLS52JH0bI94V6fSILaNXJHQ1ppQy0=; b=EEVqujFW8qtzzmGTeDyoEQAo/BELoGtnLiIY4y3QvkmVX2RZagYWtXiRO+FmgyCarG gql42ZXBKq7T3BxO8CETW8H9Y3WQr8VpQcRBcrOtK7Vz31ywVlkpEhcqvnk2L2BnpN2G 8rd4nH1fY6PKaWCz0lmGdYjCgZ+K3R0uzv+HkVZm3S3+HpEMT9vitfMDwkGFs0QDRR3D bCxmUOsEaCoRZdeJq4Tfa8aN8EuLS2mKLLgidwaxFs3tYZxzO1Cf4iYcvF+FEPBV0kSK R1K+xmTOsrpufCB9TMlBToGTew+9Xy+uUQoUUM+AqhjduKBZOTDA02BUhQTzH/O9hyS/ tKKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W9pn5ZLXOPcONTLS52JH0bI94V6fSILaNXJHQ1ppQy0=; b=BDyIsiw+EdCuqZsIBJkBr0In8E5YhpKir6BgRgXSoc+Aij5lYrZewtopUEMHKx74fG k7cdS5ALGpbjM5Ptd5UyNksVcSvSax61RtFFCDqQoBkScJ6n+AJzIvjhGPh3ijm2XQDF oe6q6zVwAqMQyYZV4q8P1qrAC7f24xqYSWorNBq1Hjawcu8Pj2hXc3q2S0hHPbboLFJy SoPaMBxVzrCeAQomna2yiWBj0nEpotM8mXzHbuKpYdY8IRpd8FvVjrSaxP8qfO2z5Te7 ZPBo/jJCLPWX+DAIyPPoC6MYM+zWUrictjKPaEivncfdFE78JtQH+aYbB1Y1uTq00xk5 tSLQ== X-Gm-Message-State: AOAM533F2AqBkwMa0grY5lPovz+CXcVUliYn/Ih0IejjqXcm4L+KCcwi +oYvLaFPfHniZYgMkTpmLsE= X-Google-Smtp-Source: ABdhPJzq8ftW0K4eUM9eDNaegEfp9iUweM5xoW5VtrWp91Jq0nYeZiL/0E8yoswrdd6gmd5ZXFv3qA== X-Received: by 2002:a17:90a:6808:: with SMTP id p8mr2474964pjj.81.1592039113094; Sat, 13 Jun 2020 02:05:13 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id o27sm7420421pgd.18.2020.06.13.02.05.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2020 02:05:12 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Roman Shpount , Paul Kyzivat References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> Message-ID: Date: Sat, 13 Jun 2020 18:05:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200612-2, 2020/06/12), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 09:05:16 -0000 Hi, > 1. Handling of UPDATE with no SDP glare This issue should have been a main scope in the first place. And there have been a lot of discussion about this kind of glare at the time of the consideration of RFC 6141. I think we can adapt the same solution. Rather, I've thought that this text was proposing such a solution. I'm not going to deny the solution with the 491 response, but I think it has a big impact. It seems strange to me that I would point this out. > 2. Handling of UPDATE transactions during initial INVITE First of all, I have no doubt that a session-timer is started when a 2xx response of an initial INVITE is received. In other words, a session-timer is not activated during an early dialog. And the UPDATE order problem is one of original(RFC3311) SIP shortcomings. RFC6141 says, if in doubt, send a refresh request to confirm. Regards, Shinji On 2020/06/13 2:37, Roman Shpount wrote: > On Fri, Jun 12, 2020 at 12:03 PM OKUMURA Shinji > wrote: > >> On 2020/06/12 16:16, Roman Shpount wrote: >>> 1. Handling of UPDATE with no SDP glare >> >> Specifically what is this issue? >> > > If both UA send the UPDATE with no SDP, according to the current > specification it is not considered glare and 491 response is not sent. If > both UPDATE transactions change session timer parameters, such as refresher > at the same time, then the negotiated result can be ambiguous. Best > solution would be to force the 491 response if two UPDATE without SDP > contain session timer parameters. > >> 2. Handling of UPDATE transactions during initial INVITE >> >> I think the simplest solution is that SE and MSE headers should be ignored >> during early dialog. Because with respect to a session-timer, 2xx response >> is the only answer to an initial INVITE. >> > > This is not that simple. > > You can have an UPDATE transaction which starts before 2XX for the INVITE > transaction is sent with 2XX response for UPDATE arriving before or after > 2XX for the INVITE depending on the network paths or network delays. If > different session timer parameters were used for UPDATE and INVITE, the > negotiated session timer is ambiguous. Also, the definition of during the > INVITE transaction is ambiguous as well. Due to network delays, it will be > different for UAC, UAS and proxies in the path. > > Another question was when does the session timer start? Is it from the time > that the INVITE/UPDATE message was sent or was it from the time 2XX > response was received. > > I am not actually looking for answers in this thread. I am just letting you > know what issues I need resolved. This group actually spent a considerable > amount of time discussing the solutions for all of this, so the best option > would be to restart the discussion for each of those issues in a separate > thread with a quick recap of what was already discussed. > > Thank You, > _____________ > Roman Shpount > From nobody Sat Jun 13 13:06:27 2020 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 82BE03A122E for ; Sat, 13 Jun 2020 13:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 ymmZyakIfe7L for ; Sat, 13 Jun 2020 13:06:23 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700060.outbound.protection.outlook.com [40.107.70.60]) (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 C12253A122D for ; Sat, 13 Jun 2020 13:06:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iSqE/oIQdHOzTMfnwIkd5uNyl1t0IiABlWsqdOAHM54K3x/1NSSHOa5A3YyO8B2gnfEZigdBuO19KgC+w63ipU/OdswPPNIOkpGu4xgXRYgPUbENYGyUdawnLo940lBcCamYzvPxaIgaqay+lhMB3njUPltxTaol+UtIBm+RkLPbvOjtU3ULo+Nb57F/BRKdx9l5/vPdAhB7t7Su6hi6u/wi7VgJRprfT0ewFqn7VospacuCsjkK5hCOo0kXmFV2hqcTnSexwoqKP+GUWbCnjfmGc4Y5yiis3Jbe4MFC4IlAF0ioJmBUrNg0dY6mGcEV2udEGCLbFqQpTX6j694WqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gSg+gQ+FU7ONM4bVuV6Otn3LyHk9pED3F9Pog4/bz4=; b=JD1bbdSwh8gxRaHwLHu7pd7m/dFgInt3HZPi12IaBd7vLtAefzwFnyPy3XT/qrWgyF8D+zEJDVANJkbWOZbpL0V5r//ZuCEDP08IaShx7eUM5rLbCRDUe+f+x8A7GsHADGhqXoyg4NFAv1ebZDtZD7tXCO/Ynnytw0qZVVTC1HH/axNqMyp8GLsRb25ZRm4coP5OxTH75AXjAPGJ8cpaPtTX6Y4tt/EKXilG4wDCvW10ZF2Lkj3LotKLk/f3J5R++KVtcJZWJlkLxYjrKAweeTO2IGO57u1rILiOc76jAFVG857AC4IpQ/AeS8f4Wz8dJzAXQjDEotCef3/w1rJgaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gSg+gQ+FU7ONM4bVuV6Otn3LyHk9pED3F9Pog4/bz4=; b=CpKkZaixgvr3pLVVC8fpGp5GEKycadpopM7vLtnmbrZND512tLCtFeSe0/K5zeADxHY5h0v2ZkYR+/qai89Q/5fIuFkhfWok/GHLGe9s/LZVJlm2hKliskGOb6Gssn2PwGeTBam5Lc+xLRReh82naox92ymsLzCZxryc6jxhcO8= Received: from SN1PR12CA0063.namprd12.prod.outlook.com (2603:10b6:802:20::34) by MN2PR12MB4455.namprd12.prod.outlook.com (2603:10b6:208:265::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Sat, 13 Jun 2020 20:06:22 +0000 Received: from SN1NAM02FT028.eop-nam02.prod.protection.outlook.com (2603:10b6:802:20:cafe::a) by SN1PR12CA0063.outlook.office365.com (2603:10b6:802:20::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Sat, 13 Jun 2020 20:06:22 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT028.mail.protection.outlook.com (10.152.72.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Sat, 13 Jun 2020 20:06:21 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05DK6Jwr024810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 13 Jun 2020 16:06:20 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <20d07be6-111a-d98c-702d-6880f0e332ad@alum.mit.edu> Date: Sat, 13 Jun 2020 16:06:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(396003)(376002)(346002)(39860400002)(46966005)(82310400002)(356005)(7596003)(5660300002)(26005)(47076004)(82740400003)(31686004)(70586007)(75432002)(336012)(8936002)(186003)(70206006)(6916009)(83380400001)(36906005)(2906002)(786003)(86362001)(316002)(478600001)(2616005)(8676002)(31696002)(956004)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0790a7f9-016d-44a6-b448-08d80fd53e35 X-MS-TrafficTypeDiagnostic: MN2PR12MB4455: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0433DB2766 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LamajaYDVNyz/+VHR2HD1KG2AOdYohm/8DCOp1fL8SKQIYq7KC13jr94gq1LzcFURV6rtczfLHzAg7ZwpDCHmqk3yvkRSYyFQf6jaRzcneFbBcQX18B5onc/avKXlDIpTdevX8/GveohOwDO739zmxbZwp6lAK9mzACnPW2xogUvfi+5ic+NTMnAOa+jvhrbTUtVckv3yfuffN/HaX251xxrGebAn0kUewc5MTWK8+rADrFnHEHx5Yp/x4Is6HWF43pzQ5q6NwHsdVIK0YPUuOHWg/v+IQFiraC0grpHWmIrNSf2blPrQdxV+qloasxCU+jaHqEeGOLUzioGUXpqi5R6vJLZ5hz00oaiFX4t7vEq3mpB1bl6zj5vyy4y4M9yFv2uLMrJOv81z2xHpxY2+SYxy8YAzMmGI7PghN3uG29cfGPDGfLFFPIoDyTaP2mk X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2020 20:06:21.4985 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0790a7f9-016d-44a6-b448-08d80fd53e35 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4455 Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 20:06:26 -0000 Hi. I did a high level review of this document. The following are the key points I identified. I didn't investigate a lot of the details didn't comment on nits since that can all wait until the overall mechanism is workable. * Section 3 says: This section uses the term "intermediary" to mean the entity that acts as a SIP UAS on behalf of the user in the network as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy. This section has the terminology scrambled. If the intermediary is a true proxy then it is not acting as a UAS. Perhaps you mean: This section uses the term "intermediary" to mean the entity that acts on behalf of the user in the network as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy. * Section 3.1: If the intermediary issues 184 as a response code, then it is *not* a "failure response code" - it doesn't indicate failure. * Section 3.4 says: We address this situation by having the first network element that conforms with this specification play an announcement for negatively rated call attempts. ... Because the ultimate disposition of the call attempt MAY be a 100-class response (assuming call goes unanswered due to negative rating), the network element conveying the announcement in the legacy direction MUST use the 183 Session Progress response to establish the media session. The 183 to provide the announcement SHOULD be performed prior to forwarding 180 ringing. While playing the announcement, the intermediary MUST suppress additional 180 and 183 progress messages. There is no guarantee that the call will fail. If the call has a chance to succeed then these actions may negatively affect that success. For instance, the callee may have important early media to convey after establishing media connections using either 183 or 180. Delaying those while playing the announcement may have negative consequences. And what is to happen if the UAS returns a 2xx response? You must address that. Presumably you want to get out of the way and let the call succeed. Also, you don't address what is to happen in the case that forking happens, either serial or parallel. That will certainly complicate things and needs to be addressed. I suggest that it would be better to delay the announcement until it is known that the call has failed. At that point you can delay the failure response, negotiate a new media channel for the announcement, and play it. Another thing to consider: what to do if the entity responsible for playing the announcement is not able to do so using the media offered in the INVITE? (E.g., the call is video only and there is no mechanism for announcing in video.) * Section 3.5: It seems you are assuming that the announcement must be made via media in the session requested by the INVITE. There might be other, preferable, alternatives. For instance it may be possible to send a text to the caller using whatever texting mechanism supported by the UAC. This is likely known to the element doing the announcement. Thanks, Paul From nobody Sat Jun 13 15:00:56 2020 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 5084C3A0F4D for ; Sat, 13 Jun 2020 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 HwpHLqshDa6A for ; Sat, 13 Jun 2020 15:00:52 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640132.outbound.protection.outlook.com [40.107.64.132]) (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 13B153A0F4B for ; Sat, 13 Jun 2020 15:00:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kjekvCnWxApfy7wpQ496kYD9GUz6VRBax9L9ZDrTE1+OFfIRKiQxDvR4DTPMcIQo88FqvDTdhDkp3et9FsBj4fChlX8I5K7A9gcoknf2huvMWLkRwpL6c7q5PXo9bweP0uwAZvl0ibKodsGxVDBY0wgjrXbBVcCg0R9cFkQ0V86M2JmfqSLMc6wsqU3nXHyeIhwZ7AKiOe0il0x5yaFf0utj0wU8YqBOlCNfNZZiHC7fm1O6/JJGpQM+6flcbS62Wac0URzygy6EHh7wDFgU1djsGH7vG31xsfRsNuPCxrBVZoE+DGEMCZq+QmexkbPFUu6OYNBOAmRarrKVkkY31A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x85Nl32zkdDdB3eVUoBMPzuWMJNyzvD3jDx2HVhDcgY=; b=UV8eoFxYKDSuUBmRfzooZYA93YtKaOW8eQ4JHM2SPtCIs8AVx/OEFGF5NyoOkeiOuHoJThXGjNp6j7naKEMVVJM5g6vGq3zIFodVGbOppItcMGjC8Moc3SyfRn79MBo//uHZkCZJFSUmyLkVQ3zcN3bBhFuz/RFNMVxT77F1bxLz2oCNXhnzYt1DiXajRG9JdNdbVrxc1w/SU0WdcwVUwtSLjFLwzgbQubxsctkfKo6eXXCvB/b66bPP12T8JBn3G7TriLvrh7SBVBbtwE0+OY2/r3Du/G7gBsxV/mG7lNhUlzEAberygNr+YH4kgjDkbEztSCtAwCefXZF2Uk8z4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x85Nl32zkdDdB3eVUoBMPzuWMJNyzvD3jDx2HVhDcgY=; b=f1fJW2MzebEUr9ENYnIQVLhUCVuVtXipsPDPD9TqB9jKGxpRfUlYIahRKZKp83s2zdGpCC9OUOltzqFx+xDfcwhEl28SRiTqZPVRVEiM669dIvWMe3sip0AQIF5C44Mt+YbOe0wDkLY0yiTGe5CAQa+FYtZySiSO1PJGP+TTTB4= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0572.namprd00.prod.outlook.com (2603:10b6:5:16c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3139.0; Sat, 13 Jun 2020 22:00:49 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::b492:d49a:9956:6f3f]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::b492:d49a:9956:6f3f%9]) with mapi id 15.20.3138.000; Sat, 13 Jun 2020 22:00:49 +0000 From: Russ Penar To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore Thread-Index: AdZBBAfA3uPUg+ERQ5G4Wnos9BXr1wAuhJCAAAMDynA= Date: Sat, 13 Jun 2020 22:00:49 +0000 Message-ID: References: <20d07be6-111a-d98c-702d-6880f0e332ad@alum.mit.edu> In-Reply-To: <20d07be6-111a-d98c-702d-6880f0e332ad@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=516bd6d2-952f-4422-800b-00006e8c0165; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-13T21:32:39Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none; alum.mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 29601970-be86-4f40-af0a-08d80fe53b6d x-ms-traffictypediagnostic: DM6PR00MB0572: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0433DB2766 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +rXfvtYB9LER3kL+fSTdFb5Hj/tbmoM/mhA7kLXLeJYp/DmCeBjzGfIC/+qeYV6yMp5UmgwSomm3RRsCMP8QW1oGW10eNBNBCMw4igBtm8AMDBPqlaMBRyHlj6MOsH4i4ythvkICdBqfHO6bLnQ9rU7LVOd696dnWt5ODh38sv/y4a4VA3G5Hw966DLnLWxQFRFi9AbtgKwSfKHC1aXmd/AN+lv+IJZsLz8R2tFu/7j0Nlw0hUbqlsstdhkWYT2KqKVfF4y99T1XI3r/Jzc/l0SvQ2Qn9WCObuMHSWypY1ZS+54uCef5qXDGiMJwDrhFJYXwi2LJxeDyYnqZbQToKzN0oh9aZ0a89GVt+YAIQcc/4He9JOsIz3rh7WROF2BcP8cSOFrQuO1IwtWEhQ+mKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(39860400002)(366004)(376002)(396003)(82960400001)(33656002)(82950400001)(8990500004)(86362001)(76116006)(9686003)(83380400001)(66446008)(71200400001)(10290500003)(186003)(64756008)(5660300002)(55016002)(478600001)(52536014)(66556008)(8676002)(2906002)(26005)(53546011)(66476007)(6506007)(966005)(8936002)(316002)(77540400001)(110136005)(7696005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ApppCBYttoVZyyEGlNXaT02lfW33LaW5uNUUZuwqofiXxtsO/tiMJ5KxN09I+LeghEjQX3uJStZeQ2wZz3bU8cTLLa85zygqgFAH7JKN/FlIhvqwoehjXxqdoE25aweYEvbm+WGuf5RvGwZjKi3n/YWJcxovSaPo/ULqbQJrAgj/ZvQVJbQUWlZITKTQZZ4T47BLK8taGPohC7ui6tnm1Q98roXbGs/ClzfaGyhZ1UzoQjsTJgZniImphH8/CVFxfNBNEzYt7vcqoAGF+ttsZ0X6EO1ogpuB6R6nLiqQBwv0El4aTFm+ZKXlCjv8u4qd/3kEq7NALwPllHjsaoqqoUFKE9EluV+ewHnwdugUZgcBxOpJUUCBz0P5HyvY20RmKGveVmQ3BqiK+Y5OjQYOJIRlo4oypKcDFl8pBdUvC4h28YYTaGxI3ut+P1A2q0OHxkABLdYODCp0vxzjxupibQ6KCFZ4KDJHlRAZEl8t2f0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29601970-be86-4f40-af0a-08d80fe53b6d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 22:00:49.0697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DLMXfmVGNRE8/IlQQAH/aeEKAmRM8ZH2b+dIVgNLqxLijRnGY3CYBsvm5D/sqJAwppbgjAoRLg9Quy3zD/2StQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0572 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 22:00:54 -0000 Hi Paul, Thanks for the feedback, this is great! As a general process question, do folks normally work out new/proposed lang= uage in email before publishing the next iteration for review? Just looking for best practice and what works best for the WG.=20 *Section 3 - fair, I thought UAS made sense because it could be handling pr= ocessing for the user. The spirit is exactly as the adjusted language stat= es so I'm OK making the change if intent is clear. =20 *Section 3.1 - Oops, yes, will fix!=20 *Section 3.4 - The more I think about this, the less I think we should invo= lve any announcement at all. Given there's really no failure in this scenar= io (if there were, a 607 or 608 would be used), call either is not answered= or goes to voice mail. I just need to provide a signal back hinting as to= why the call went unanswered.=20 So maybe, as you alluded to wrt text mechanism, it's enough for the provide= r and the last IP endpoint (e.g. analog gateway) see the message and the us= er is informed either through debug or some out of band mechanism (e.g. As = part of my user invoice, I get to see a list of my call ratings at all the = networks I called)? *And what is to happen if the UAS returns a 2xx response? - 2xx does not i= mpact the scenario once we remove any chance of announcement, either voicem= ail or caller picks up "scam likely" call. *Also, you don't address what is to happen in the case that forking happens= , either serial or parallel. - Another good point, I will call out this cl= ass of scenario, thinking I'd use simul-ring as an example. I will add the= language, but high level I don't think the call flow changes here beyond U= AC gets feedback on call-rating from each endpoint/network it targets. =20 *Section 3.5 - Fair, see my reply to 3.4 as to why this may be moot and ple= ase let me know your thoughts.=20 Best regards, Russ -----Original Message----- From: sipcore On Behalf Of Paul Kyzivat Sent: Saturday, June 13, 2020 1:06 PM To: sipcore@ietf.org Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-= ietf-sipcore Hi. I did a high level review of this document. The following are the key p= oints I identified. I didn't investigate a lot of the details didn't commen= t on nits since that can all wait until the overall mechanism is workable. * Section 3 says: This section uses the term "intermediary" to mean the entity that acts as a SIP UAS on behalf of the user in the network as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy. This section has the terminology scrambled. If the intermediary is a true p= roxy then it is not acting as a UAS. Perhaps you mean: This section uses the term "intermediary" to mean the entity that acts on behalf of the user in the network as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy. * Section 3.1: If the intermediary issues 184 as a response code, then it is *not* a "fail= ure response code" - it doesn't indicate failure. * Section 3.4 says: We address this situation by having the first network element that conforms with this specification play an announcement for negatively rated call attempts. .... Because the ultimate disposition of the call attempt MAY be a 100-class response (assuming call goes unanswered due to negative rating), the network element conveying the announcement in the legacy direction MUST use the 183 Session Progress response to establish the media session. The 183 to provide the announcement SHOULD be performed prior to forwarding 180 ringing. While playing the announcement, the intermediary MUST suppress additional 180 and 183 progress messages. There is no guarantee that the call will fail. If the call has a chance to = succeed then these actions may negatively affect that success. For instance, the callee may have important early media to convey after est= ablishing media connections using either 183 or 180. Delaying those while p= laying the announcement may have negative consequences. And what is to happen if the UAS returns a 2xx response? You must address t= hat. Presumably you want to get out of the way and let the call succeed. Also, you don't address what is to happen in the case that forking happens,= either serial or parallel. That will certainly complicate things and needs= to be addressed. I suggest that it would be better to delay the announcement until it is kno= wn that the call has failed. At that point you can delay the failure respon= se, negotiate a new media channel for the announcement, and play it. Another thing to consider: what to do if the entity responsible for playing= the announcement is not able to do so using the media offered in the INVIT= E? (E.g., the call is video only and there is no mechanism for announcing i= n video.) * Section 3.5: It seems you are assuming that the announcement must be made via media in t= he session requested by the INVITE. There might be other, preferable, alter= natives. For instance it may be possible to send a text to the caller using= whatever texting mechanism supported by the UAC.=20 This is likely known to the element doing the announcement. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Crussp%40microsoft= .com%7C0986d8b847e34635fb0408d80fd544fd%7C72f988bf86f141af91ab2d7cd011db47%= 7C0%7C0%7C637276755949190049&sdata=3Dd7QRycFviYGL6qC8s7ttbZLj9teu4%2BdA= 1L721s4i6JY%3D&reserved=3D0 From nobody Sun Jun 14 02:47:14 2020 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 0F83D3A0D2C for ; Sun, 14 Jun 2020 02:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAujfMFq7jMf for ; Sun, 14 Jun 2020 02:47:11 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 242103A0AD7 for ; Sun, 14 Jun 2020 02:47:11 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id b201so6506089pfb.0 for ; Sun, 14 Jun 2020 02:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=2iacP11plQIqhSF4nn2azTA+MxbiLQ5+av/MFYfVCHE=; b=gXlx4qRsXfo6Cd1js8WahdPeFlyp9vwfUee2rRZVliyrpp0sWcRAlkfPKIoXqObBog iHNIyCQ7mvROf9CT5D0ZbKgtvAwb6Vgjp60QVYrXn+vr/bt6L3fZ1Wbo+9iSJ6RRDXrj WpkRmJRCvyI5ZHby8MzFOcQMS5T3xw4dB7YNYF0rTIXqB7tKOhXquWjUyQZMQCn7YkbJ LIRX4a4mSrSroJHM34Ze3JjeoHnk5B4NXdEy2E9Ut6OB4BKf+dUso65Q8oMoKP5upfL1 aWo1OzYR2FwKNBpW7RZfr8dr7TGdR15PraKeQnSqbFWCwW8Bge81Si1rA6qpsJZLbXrH S0wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=2iacP11plQIqhSF4nn2azTA+MxbiLQ5+av/MFYfVCHE=; b=m4WH9SXrgsMAbu+Gv5lh4jt7MgwT0LgATkL1+Y7X1Qt7HHdvAeFCGW5YjfU52qLQeb MXbCw876xzVzIM8M97nA3QYfTPEWpqbDt3W4XhsgMhUAWYFm9yl/gmN5ypObcUF42Ac/ 9l7PED81JZHg3vaODfCmN4s8aV3j6V3snnxfyl78SmwldUOadKy39ACAvMVHa8xM3XJ2 OekkY8SK4xcly0r6s+2neJC+XH86yHRuqBv7eULzm0bquEiiE6otcOAlc3A/1mHne+Ca 7lne0958hYS4WgH/oq7qWeVR/i1p66g7ApSzC+ZXvjV2lUJSO3XCK5jZikLfxIE3opaJ 8gFg== X-Gm-Message-State: AOAM531iIQ74WpKavotLOZEN/L53wmhLpdpOAoiR71LLtk3Di0CgI3ps CUwKCqQc38yCdIEtjGjJGZSf/bc2 X-Google-Smtp-Source: ABdhPJxCCkfnPUnl4qc8QMqphdHt8pWfMd3+95Iyw6uDWqxP5diW97KpvHNlSOdLLo+PW7CMiIdwVg== X-Received: by 2002:a62:ce01:: with SMTP id y1mr19495868pfg.112.1592128030509; Sun, 14 Jun 2020 02:47:10 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id m4sm8973976pgp.32.2020.06.14.02.47.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2020 02:47:10 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Message-ID: <37a98507-115d-168a-459d-bceae65d71d6@gmail.com> Date: Sun, 14 Jun 2020 18:47:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200613-8, 2020/06/13), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [sipcore] RFC4028 : Clarification of "turned-off' in 7.2. Processing a 2xx Response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 09:47:12 -0000 Hi, Section 7.2 says, If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field. I understand the following. The current specification allows a UAC and proxies to add the SE header to the INVITE request, and a UAS and proxies can also add it to the 2xx response. In addition, IIUC, if a request contains a SE header, a UAS must include a SE header in the response. As a result, only if all entities do not want a session timer, the session timer is 'turned-off'. And in practice, once the session timer starts to be used, it is rarely turned-off. Because section 7.4 says, In a session refresh request sent within a dialog with an active session timer, the Session-Expires header field SHOULD be present. As such, a UA should only ignore the SHOULD in unusual and singular cases where it is desirable to change the session interval mid-dialog. Regards, Shinji From nobody Sun Jun 14 12:42:14 2020 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 040E93A10A4 for ; Sun, 14 Jun 2020 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_PHARMACY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 brYnbPoj7eP5 for ; Sun, 14 Jun 2020 12:42:10 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ADA3A10A6 for ; Sun, 14 Jun 2020 12:42:10 -0700 (PDT) Received: from [IPv6:2607:fb90:a69b:91a5:88d4:b062:1bcb:25f3] (unknown [IPv6:2607:fb90:a69b:91a5:88d4:b062:1bcb:25f3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 8926D4E11A6E; Sun, 14 Jun 2020 19:42:09 +0000 (UTC) From: Cary FitzGerald Message-Id: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C84AFDB7-EFC2-4A63-B4DF-72014CA597D6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 14 Jun 2020 12:42:19 -0700 In-Reply-To: Cc: "sipcore@ietf.org" To: Russ Penar References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 19:42:12 -0000 --Apple-Mail=_C84AFDB7-EFC2-4A63-B4DF-72014CA597D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not a fan of the use case. Sharing details about per-call = spam ratings with potential spammers seems unwise. In the real world, calls marked =E2=80=9Cspam likely=E2=80=9D that come = to my phone are answered by voice mail. Most spammers won=E2=80=99t = even bother with the airtime to leave a message. The pharmacy from the = introduction would do that, presumably. It=E2=80=99s unlikely they=E2=80=99= d do more in order to reach a single callee. Fixing large scale = problems (inter-SP) is larger problem. This mechanism is value-neutral: legitimate callers are not = distinguishable from bad actors. Bad actors *might* abandon the field = if they see they are marked as spam, or they might try to adjust their = attack to lower their scores. I can=E2=80=99t think of a similar = mechanism for email beyond managing one=E2=80=99s reputation. Fixing the analytics SP=E2=80=99s logic for legitimate caller would = certainly include the caller's assertion of identity. I see a = conceptual difference between STIR and this approach, but I=E2=80=99m = not sure I see a significant advantage to making the assertion after the = fact. The most obvious metric for an "analytics service provider=E2=80=9D is = reputation and identity is the key. Asking out of ignorance, are there = market-driven requirements calling for something more? Cary. > On Jun 12, 2020, at 5:01 PM, Russ Penar = wrote: >=20 > Based on early feedback, I updated the name and proposed code number. > Please review the newly named draft, I welcome everyone=E2=80=99s = perspective, thank you! > =20 > https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ = > =20 > From: Russ Penar=20 > Sent: Friday, June 12, 2020 2:55 PM > To: 'sipcore@ietf.org ' > > Subject: please review and comment on draft-penar-ietf-sipcore > =20 > Hi All, > Please take a look at my proposed draft regarding a 1xx message = letting caller know their call is rated poorly/ambiguously. > One early feedback is 184 may be too close to progress messages = associated with ringback, and I=E2=80=99d love to get more perspectives. > https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ = > Best regards, > Russ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_C84AFDB7-EFC2-4A63-B4DF-72014CA597D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m not a fan of the use case.  Sharing details about per-call = spam ratings with potential spammers seems unwise.

In the real world, calls marked =E2=80=9C= spam likely=E2=80=9D that come to my phone are answered by voice mail. =  Most spammers won=E2=80=99t even bother with the airtime to leave = a message.  The pharmacy from the introduction would do that, = presumably.  It=E2=80=99s unlikely they=E2=80=99d do more in order = to reach a single callee.  Fixing large scale problems (inter-SP) = is larger problem.

This mechanism is value-neutral:  legitimate callers are = not distinguishable from bad actors.  Bad actors *might* abandon = the field if they see they are marked as spam, or they might try to = adjust their attack to lower their scores.  I can=E2=80=99t think = of a similar mechanism for email beyond managing one=E2=80=99s = reputation.

Fixing the analytics SP=E2=80=99s logic for legitimate caller = would certainly include the caller's assertion of identity.  I see = a conceptual difference between STIR and this approach, but I=E2=80=99m = not sure I see a significant advantage to making the assertion after the = fact.

The most = obvious metric for an "analytics service provider=E2=80=9D is reputation = and identity is the key.  Asking out of ignorance, are there = market-driven requirements calling for something more?

Cary.

On Jun = 12, 2020, at 5:01 PM, Russ Penar <russp=3D40microsoft.com@dmarc.ietf.org> = wrote:

Based on = early feedback, I updated the name and proposed code number.
Please = review the newly named draft, I welcome everyone=E2=80=99s perspective, = thank you!
 
 
From: Russ Penar 
Sent: Friday, June 12, 2020 2:55 = PM
To: 'sipcore@ietf.org' <sipcore@ietf.org>
Subject: please review and comment = on draft-penar-ietf-sipcore
 
Hi All,
Please take a look at my proposed draft regarding = a 1xx message letting caller know their call is rated = poorly/ambiguously.
One early = feedback is 184 may be too close to progress messages associated with = ringback, and I=E2=80=99d love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<= /span>
Best regards,
Russ
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_C84AFDB7-EFC2-4A63-B4DF-72014CA597D6-- From nobody Sun Jun 14 17:25:40 2020 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 879CC3A07E7 for ; Sun, 14 Jun 2020 17:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 lQvL6fr4XKQ2 for ; Sun, 14 Jun 2020 17:25:37 -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 6E4123A07DC for ; Sun, 14 Jun 2020 17:25:37 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id kcrsjNWFVKcgOkcwSjMGqF; Mon, 15 Jun 2020 00:25:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1592180736; bh=HTsk9VmUtQR1nPjhpO7wAXm6+lcfqSOEpUsdP6yhrN4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=RttkgZesacTGC5fF/CNVPuOxDEj6NSQCHvgc6DR+s5XWuPX3SwZ3B+tY7xyodgR6a gd+zS1nyU0zVMfJ955Zi6lNvqh0v4v/IVh5fcjX9iwUEWpeZwgaQ5mjPXuz1aXO01w hcN5EMrrK6LCe6slFw2Jklgghj8salbq7ZiNvw8tfjzwoXcBy7o0o/gxnyUxihEov+ QjCzYiL3n5tKTpk3t2L/Hsgsyfv8jxdEBAKByAuVps13sp0hzGIY2UpkJ5to7DS5Ah m8FlEYIXUXNvy2GF7l5pYxqTR3ppCOAR3jHIJiKe3/vKqYy5xffdQRxlFwYbDPLGY6 FS5G4HsqIbzNA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id kcwQjAU4vX6TlkcwRjyti8; Mon, 15 Jun 2020 00:25:36 +0000 X-Xfinity-VMeta: sc=0.00;st=legit 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 05F0PYar028807 for ; Sun, 14 Jun 2020 20:25:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 05F0PXqC028794; Sun, 14 Jun 2020 20:25:33 -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 In-Reply-To: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> (caryfitz@employees.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 14 Jun 2020 20:25:32 -0400 Message-ID: <87blll5g5f.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 00:25:39 -0000 I don't know of this question is related to this draft, but reading about this draft brings it to mind: It seems like an ideal system would allow the potentially-spam caller A to put some sort of token in the INVITE which would be recorded with the voicemail message to the callee B. Then if B wanted to contact A, B could send an INVITE that includes the token, thus allowing A to process B's call as a continuation of the original call. Similarly, B's call-back could include a token that A could attach to future INVITEs to B as evidence that the call was approved by B and thus avoid being spam-filtered. Dale From nobody Mon Jun 15 01:40:47 2020 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 457A53A0AE5 for ; Mon, 15 Jun 2020 01:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 m2OdXmg62XFg for ; Mon, 15 Jun 2020 01:40:41 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2067.outbound.protection.outlook.com [40.107.22.67]) (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 55A513A0AE6 for ; Mon, 15 Jun 2020 01:40:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GXa7/5vF/LHLjvTCT5NhLCid87NANi+WuIzSyVphNtSxXOP0OXukYlDfSqJPRCKG09TLv73sspXH69hMAXHCUbJ2ZX7IkAYetTEkRi6hPW+Df19HRShzDSiokBN4dqT75ny0nuxikt8Horu77FvoHg4m0Y3fnHiVOyamhmyuCInMqvmdryTlas4DeV0J7R1sFlL3F+qhBRj0jcgIrhPZwuZPQfsEEKzoZJfEv8dYQUwhD19z0pLt2EV6XZAaTH7cJwxheXJjCZWB7ZY0ttfy2qIHf0CsmkxI3LwJlGxrr1dtsspE5boiubhK4BjRox0ZX6RJbLq5EnPp5FfF8QG75w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bI/G4Rm58R3/AB2Y0O187yfg/OHy2Qgc2Su1JCW/Q4c=; b=XDhvear11ngM+LGcoW/lU07D5PgvaLIibxV9vjumqdl3GGZU4pX5a44J1/pH8gnDyEkEXsWSQWLWr2I10+X5oenYtMR485P9PgBjQ2/bdafdMfqNBnvzs8VkT3jsaUf1v7FbrkS1tjVSk6FAQscSBPT9Iz4T+rf+QrqMX+iuPR5bNmKatF3fJGd1WeXlYB+7wTu40iseTg3rRh1xghiSByuAcYDBqVRdTSX0L/ENKIC8iTGALGIgxWZhBLp8HfSx0hgA/A5vmRWQkeqVr5gUtOoeBFclXjkeWZ9n4NS+/ZXICZWqzSgdkpveQDFNoW0YWEtHwdCLJLeKyM0lN642mA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bI/G4Rm58R3/AB2Y0O187yfg/OHy2Qgc2Su1JCW/Q4c=; b=c888UO7j/+yC8CG04ow/AfzkI84OiUYFc/QPWg7eCgVnTObjO/Sf269bKWIiQD53ezWUOQtBJ6jr/nnh2ltKUejaZktAtmgyrm6AjSCfWb4jdTqjz7qwq6soY9R5FdWRfcN89UXbZ96JdMsq42l4bxgWpvhmst1RCQq+FQxMCw0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM6PR07MB5107.eurprd07.prod.outlook.com (2603:10a6:20b:5e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.11; Mon, 15 Jun 2020 08:40:35 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3109.018; Mon, 15 Jun 2020 08:40:35 +0000 From: Christer Holmberg To: Russ Penar , "sipcore@ietf.org" Thread-Topic: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AdZBFbmIYErjvgZESFeR9rthnkycuwB2qu6g Date: Mon, 15 Jun 2020 08:40:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6de2e19-785d-403b-9c7e-00006df9e7a1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T21:51:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bffbcf8a-5a7a-4c60-c9a1-08d81107c5d4 x-ms-traffictypediagnostic: AM6PR07MB5107: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1SATi8sDPRilQlbW2VJ9tYQyZ62cNM3Ajz8rOUJ++yl4TbiGagurynkZBDEfXoZfG/w3XEuZdTUl2iuY7IEpoaJKIQEIsH8+bN3t4kHAXuPKOAaJJnXNa+UTISbSxestzhXZSW1iUIS3bGMbSWB80C/m5AupOfH2xu/WyPSRzFFp/3GZyS60C9whu+o4NmQgxZhCninDCxY4NHfdYc+2Ez1A8pU2zDpt+U8YFawSrDwxlxGxSvh0zv8sCxkp5Cb0N39EGLdKjKG/0KDvuyDOiQzD27VPEaCa577Hqvv5tRt2BdpULgPLOc7Bcaz7HSSRGk3B0bsCRhWduAw+4APPyzrk26rl40HsbaivLaloa6Tdn5289RAfQbbPT61OvvW0WnbJ/G1Jm54PPNWKpLClNg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(33656002)(83380400001)(26005)(8676002)(316002)(110136005)(55016002)(2906002)(9686003)(478600001)(966005)(66574014)(166002)(7696005)(8936002)(5660300002)(76116006)(66446008)(64756008)(86362001)(52536014)(6506007)(71200400001)(53546011)(44832011)(66476007)(66946007)(186003)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: e6B26CFZlYZ6GhMnJMpIbsAHMRW63Hb1a0tG6jFzHTRCqDWT8PObypSxPZmpgFCdVVp1sn1P8crHjbheyDjNJPUvkw3m/jBrJ3y2qDaGBlJL8AAFjqnGE69B3NY2HLBJHWYhJ7YPnaf1IpLNTHkm8ztiedXXJTkDeIEp/a5GEnXDMHaFVtyImigzz/TtY+CX/TwGG4j5/clt/KhhzDXUDZeTQTKWCEQspCtfTliglCVmHn8iarHr9M7G7T7T8I/4Pjkd+oEFw/JJ3gzxFfe00MRXvb28oKdcKOt7xGOwGzHu9dr7w4oXKZcYUkIAoOYc3L/YwSW/JQH7sIBFHQ/1NhPHJYpGXIY8XYvvOy+fOQuxZwsOQFh2iCzjBftRmwuf/SIWIiA91OY+zgBijjDjOYviL0y5aTGRhwFEg7VEviGiHA/Ngsx9Qji8T8dwZ4nlc2kY+sItGhH5usJhCMm51AjatBrEkIFvmZqap/QiP5Dh/++8XoI4q92XwievG06K x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB701283B86A38E75C965C5C99939C0AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bffbcf8a-5a7a-4c60-c9a1-08d81107c5d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 08:40:35.3907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DEzzYIaj6fUX+xBsFUXu5yJvfOQo8cY5J6H/YSlGb3WV/aPPZGvRUsLBcfDSlUS8DongreK8XS721S5HQgw81tWjjLAT80Y5jWNVpXHFFq4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5107 Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 08:40:43 -0000 --_000_AM7PR07MB701283B86A38E75C965C5C99939C0AM7PR07MB7012eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, If needed, why can't the called party proxy forward the call to an announce= ment server, instead of relying on the fact that there is an SBC somewhere = that supports the mechanism and is able to play the announcement? Regards, Christer From: sipcore On Behalf Of Russ Penar Sent: lauantai 13. kes=E4kuuta 2020 3.02 To: sipcore@ietf.org Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingp= rovided-00 Based on early feedback, I updated the name and proposed code number. Please review the newly named draft, I welcome everyone's perspective, than= k you! https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ From: Russ Penar Sent: Friday, June 12, 2020 2:55 PM To: 'sipcore@ietf.org' > Subject: please review and comment on draft-penar-ietf-sipcore Hi All, Please take a look at my proposed draft regarding a 1xx message letting cal= ler know their call is rated poorly/ambiguously. One early feedback is 184 may be too close to progress messages associated = with ringback, and I'd love to get more perspectives. https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ Best regards, Russ --_000_AM7PR07MB701283B86A38E75C965C5C99939C0AM7PR07MB7012eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

&nbs= p;

If needed, why can’t the called party proxy forward the call to= an announcement server, instead of relying on the fact that there is an SB= C somewhere that supports the mechanism and is able to play the announcement?

 

Regards,

 

Christer

 

From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Russ Penar
Sent: lauantai 13. kes=E4kuuta 2020 3.02
To: sipcore@ietf.org
Subject: [sipcore] please review and comment on draft-penar-sipcore-= ratingprovided-00

 

Based on early feedback, I upda= ted the name and proposed code number.

Please review the newly named d= raft, I welcome everyone’s perspective, thank you!

 

htt= ps://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/<= /o:p>

 

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: 'sipcore@ietf.org' <sipco= re@ietf.org>
Subject: please review and comment on draft-penar-ietf-sipcore<= /o:p>

 

Hi All,

Please ta= ke a look at my proposed draft regarding a 1xx message letting caller know = their call is rated poorly/ambiguously.

One early= feedback is 184 may be too close to progress messages associated with ring= back, and I’d love to get more perspectives.

https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/

Best regards,=

Russ

--_000_AM7PR07MB701283B86A38E75C965C5C99939C0AM7PR07MB7012eurp_-- From nobody Mon Jun 15 05:46:23 2020 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 AFB4A3A0D55 for ; Mon, 15 Jun 2020 05:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 lY9zGdX0fsCm for ; Mon, 15 Jun 2020 05:46:20 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (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 083543A0D54 for ; Mon, 15 Jun 2020 05:46:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XfhSts0Y1CIf2fRhxbZwQxErQ5dhCcbHP8fF6/8zO2JSTUyDY+axeCrjpZmDWdOq8/r6mKZ3Fu2y7sbyy+79NKCOodRvndVCG7+CGukjgcBVYj5iFMfIGZHCaJIzRAb0bD/waPhHH3Q38f+aYdTNLyLX8lZG2d22XKaXvDA+glUzICoMHv8keufmN6Fn9cpqHeCPkhNdQmiV3xa3R5aEWvA6GXJ8kvEhP1JeXs7BJU3wSl+3NTev3sEbEikmLJQODpzkswkCuhak4sTMxj5htoWbC391DdFal1y0y95VpzQR/ty1Ouh/cootEJOn84uUhYBx0ImthzoTgK4CpL9ZVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZRvIDaU5BWvWpsWBg10lmuxQ4gSofiPllHceBGZ+IBw=; b=SFK4CieuA4qNbAzuudZ6ux44hpNAccUFxpSjVovy42hEzr95+4IGr2CFek0tS3q3fdNNa0PlkSf5r3MGqKnub17dxvGfBkZmHmGrKsyiOj4U0OhzZ7h/Yq2Fjh+498u5jTIDlt+LSBESsOiYsnjSnLBMt/f7grIVa1pz+aQrg4nq8/CCMCVVZZ8TRoQg9CCjqjsbZZBYFgKP/oBtsNCH2ikuAVIjNAE/L7owEiyjO9yPwhq5lkLigr27zhUYSLJrafRYNVxU2V7x5NWrd5AH2y2bsCmLc6t1EEwJ5iqrH0YPsD5IgJ9PRRCUFJc1Jb6oF7UgcshnCmV0YkvzrvSpig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZRvIDaU5BWvWpsWBg10lmuxQ4gSofiPllHceBGZ+IBw=; b=dOqUgmA71xKPKNrYrPx8K4Pfa10Qt0HxVUICnKNUHntHYNkQNfHGmkys2+tM5zNcEgqmxA6COz9W2p+3zaKOpuiWOi4xaTQbwZt3O2EmIJvllWIzGby8AhsbxR1J7SqMXq3ZA7LMkUct7b4rAXnG6OMawtjGdDkPWgQ3/7+C4VY= Received: from DM5PR00MB0423.namprd00.prod.outlook.com (52.132.129.35) by DM6PR00MB0765.namprd00.prod.outlook.com (20.179.167.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3143.0; Mon, 15 Jun 2020 12:46:18 +0000 Received: from DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151]) by DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151%6]) with mapi id 15.20.3143.000; Mon, 15 Jun 2020 12:46:18 +0000 From: Russ Penar To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AdZBFbmIYErjvgZESFeR9rthnkycuwB2qu6gAAiOOoA= Date: Mon, 15 Jun 2020 12:46:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6de2e19-785d-403b-9c7e-00006df9e7a1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T21:51:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 777151c0-760c-408a-289e-08d8112a1925 x-ms-traffictypediagnostic: DM6PR00MB0765: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s4nsRZvsmygjjHAxiKz/3LkmKQpPibXNN19yKxVeV6lWmY81UDpVMO5GXS7CbMzQugzRucyTcdppg2t+xh+1CPtcf2T/MZvBk2T2PLkiut1pIJxFFbJs/oVv/4KXu8hyoo16SpXs9kjJeSjnH2tNKZsM/cgEwp7DWHSmS3J19VhMNY84BqLxuhi58++6eUeAU0N3gQSyN9/OEwPoy1NpMbKxXlubQ9ulGqrwy3fCCKqiDyhqDj7I76n444M3KpRBWqEIRiNaZNr89bc6pwRhMNSFn+8qHW5pWrI1bMuA7Ozj2a/jJmXGjjyyUn8gG5amjbQMcblry1ZDWfmRXCsZzzu/uXTFEa65PsOF1k8pxiXyEFvAy7y2YythKwOvnUlztk4Dbtk52FadkpASsQKrMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0423.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(82950400001)(82960400001)(7696005)(966005)(86362001)(5660300002)(26005)(52536014)(2906002)(76116006)(64756008)(66476007)(66946007)(10290500003)(110136005)(478600001)(186003)(9326002)(316002)(77540400001)(33656002)(66446008)(8936002)(9686003)(66574014)(53546011)(55016002)(6506007)(83380400001)(166002)(71200400001)(66556008)(8990500004)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: IlmyieK4MB2frO9QQS/MJ9oQWynO28lGNtnHIhIxEe7FwW0omf83sZA/TNfd0fdzmy5bEcGU6ajOvXHFwhCZJCds6+R8budHAQyCy1DuvgfqQeOY5ixGsi0sSE/COXyXoEJtioHmcfdOF8jzJ3n2ip3URr8Qc/9wVf/15jnU9UusSxErHXDgMPa0qPoVpZ5UTiEok0TxBtgT+3zbV28GxEi3fcb4YT2s1PD41StmOwpCnK+Ke2MV6ts2kQAB0q8ImD++BatdQho7doub+0cgBor+24HJW6A1rA1dOwFhBYvjssqjZcy1OuJXDV7A5z9dCuhF7633QL63smrwv7Uswy0VvF/tok0b6RjnncULAqbWF3YKlMU1gJl3DtbgC8l9NVSifJ0yVCk6t08yh2V1QFJNjVJujWUFVMaj53pm3Zct7ciebPVVY6eG0bTBy4piwO8SE8Dc3dFkTURpV/1e02SAzEw4PNQjjizgHHYgZr0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR00MB042357AE7F81F555A7A78BA9B69C0DM5PR00MB0423namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0423.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 777151c0-760c-408a-289e-08d8112a1925 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 12:46:18.0000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j4A7xUJwG4+xBCChvJ9QBHI5/b2vxJ7Z0ubg7U0V4EFtKkYijiCaPD2CFtQWctgGs+rlzoW9ZW2BdPtkwJ9+JA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0765 Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 12:46:22 -0000 --_000_DM5PR00MB042357AE7F81F555A7A78BA9B69C0DM5PR00MB0423namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, I'm reconsidering the announcement idea, I'm not sure it makes sense outsid= e of a failure context. Given there's no failure, caller either gets no answer and cancels the requ= est or reaches voicemail/announcement. What do you think? Best regards, Russ From: Christer Holmberg Sent: Monday, June 15, 2020 1:41 AM To: Russ Penar ; sipcore@ietf.org Subject: [EXTERNAL] RE: please review and comment on draft-penar-sipcore-ra= tingprovided-00 Hi, If needed, why can't the called party proxy forward the call to an announce= ment server, instead of relying on the fact that there is an SBC somewhere = that supports the mechanism and is able to play the announcement? Regards, Christer From: sipcore > O= n Behalf Of Russ Penar Sent: lauantai 13. kes=E4kuuta 2020 3.02 To: sipcore@ietf.org Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingp= rovided-00 Based on early feedback, I updated the name and proposed code number. Please review the newly named draft, I welcome everyone's perspective, than= k you! https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ From: Russ Penar Sent: Friday, June 12, 2020 2:55 PM To: 'sipcore@ietf.org' > Subject: please review and comment on draft-penar-ietf-sipcore Hi All, Please take a look at my proposed draft regarding a 1xx message letting cal= ler know their call is rated poorly/ambiguously. One early feedback is 184 may be too close to progress messages associated = with ringback, and I'd love to get more perspectives. https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ Best regards, Russ --_000_DM5PR00MB042357AE7F81F555A7A78BA9B69C0DM5PR00MB0423namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

I’m reconsidering the announcement idea, IR= 17;m not sure it makes sense outside of a failure context.

Given there’s no failure, caller either gets n= o answer and cancels the request or reaches voicemail/announcement.

 

What do you think?

 

Best regards,

Russ

 

From: Christer Holmberg <christer.holmberg= =3D40ericsson.com@dmarc.ietf.org>
Sent: Monday, June 15, 2020 1:41 AM
To: Russ Penar <russp@microsoft.com>; sipcore@ietf.org
Subject: [EXTERNAL] RE: please review and comment on draft-penar-sip= core-ratingprovided-00

 

Hi,

 

If needed, why can’t the called party proxy fo= rward the call to an announcement server, instead of relying on the fact th= at there is an SBC somewhere that supports the mechanism and is able to pla= y the announcement?

 

Regards,

 

Christer

 

From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Russ Penar
Sent: lauantai 13. kes=E4kuuta 2020 3.02
To: sipcore@ietf.org
Subject: [sipcore] please review and comment on draft-penar-sipcore-= ratingprovided-00

 

Based on early feedback, I updated the name and prop= osed code number.

Please review the newly named draft, I welcome every= one’s perspective, thank you!

 

https://datatracker.ietf.org/doc= /draft-penar-sipcore-ratingprovided/

 

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: 'sipcore@ietf.org' <sipco= re@ietf.org>
Subject: please review and comment on draft-penar-ietf-sipcore<= /o:p>

 

Hi All,

Please take a look at my= proposed draft regarding a 1xx message letting caller know their call is r= ated poorly/ambiguously.

One early feedback is 18= 4 may be too close to progress messages associated with ringback, and IR= 17;d love to get more perspectives.

https://datatr= acker.ietf.org/doc/draft-penar-ietf-sipcore/

Best regards,

Russ

--_000_DM5PR00MB042357AE7F81F555A7A78BA9B69C0DM5PR00MB0423namp_-- From nobody Mon Jun 15 07:15:37 2020 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 E665A3A07E2 for ; Mon, 15 Jun 2020 07:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 eS-lrx_sWk-c for ; Mon, 15 Jun 2020 07:15:34 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2074.outbound.protection.outlook.com [40.107.94.74]) (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 C46CA3A0DA5 for ; Mon, 15 Jun 2020 07:15:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mEvngi57+MMcrce7rbpu2KUplPYsWy91TwAiSPGi6OpidX5cJH2IL94q2wJE/Fykb5mxCb3US04ods/tsKgYW5uIBfdjNiMbBEGd6HjUDkGUzyQ0XXi76w33Bpa4u+4tRhxN8PXm+n0Yeq564STRUiv9HBic3l/HPlqck1bcEyQ3l2EZm0b3nFFbykoiVyi+pczHaRkW1jCNvb8ptDEuhQjiIEzFWlp4719wUY/Li4S/FK4svsYXHkDmmeUPO4LnYBPFPGBB2LDSxbOukdNo1PTHh36TnlKd1mQzIkzBSCC8rwWQlOwwZtnLKwbXqY2tX//f5Zk3n598hdeaKm1Ufw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yf/IKCEf5nfpJP4M6ygNZfbXDOqeZE8LTA1KKKEy8pk=; b=HU0jpvWt70Puy8YhOXOoXXZrcE1wVOrDdjdBVNt7eo1r5oWqavJQtQ92bIKpTw90amsCqXICo1Qr9IUZzSd645+le/th6VKf16KACHaXobF9nxffYphysTxnOETv+6Cd//JmMFJCu2G6dJu9iAQSkJMYo6jFmPns+ZGAqxTPpyz7EGM+kwdaf5M+VhznupJ7OnY3VsDiQ1Ewp2aG4hirkv62s7oDMQb2u654ZQCwlVv+45EqgJCj3VJY2cuaXg0H/yETnXm/kKxqqsALNqWO/epcX8lIXWdUW0KFeLv2ch8pCXRET0nMadtdj5xOKgPPZa5VYUQc1mKva6A4A0x57A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=microsoft.com smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yf/IKCEf5nfpJP4M6ygNZfbXDOqeZE8LTA1KKKEy8pk=; b=Wo0hubOhIm97ZvEkg3lhZRex28+sGvly8WOZBNVVBtd+TSbN4jMrcMgQ4kEMzUXKqaa+qefY4U7j8bZaOA3se6cM1E/a/OwO0awFOuk43FQEuFpriviosI0XZGsdLmHITn313fTeZkjYCLhTcWmxndPgYrDs94470TO8skEohsA= Received: from MN2PR04CA0016.namprd04.prod.outlook.com (2603:10b6:208:d4::29) by MN2PR12MB3152.namprd12.prod.outlook.com (2603:10b6:208:ca::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Mon, 15 Jun 2020 14:15:33 +0000 Received: from BL2NAM02FT049.eop-nam02.prod.protection.outlook.com (2603:10b6:208:d4:cafe::25) by MN2PR04CA0016.outlook.office365.com (2603:10b6:208:d4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Mon, 15 Jun 2020 14:15:33 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; microsoft.com; dkim=none (message not signed) header.d=none; microsoft.com; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT049.mail.protection.outlook.com (10.152.77.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 14:15:33 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05FEFVjf030723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2020 10:15:32 -0400 To: Russ Penar , "sipcore@ietf.org" References: <20d07be6-111a-d98c-702d-6880f0e332ad@alum.mit.edu> From: Paul Kyzivat Message-ID: <44ef1efd-6446-7f03-8c25-f7a04579ac90@alum.mit.edu> Date: Mon, 15 Jun 2020 10:15:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(346002)(376002)(136003)(396003)(39860400002)(46966005)(83380400001)(70206006)(70586007)(336012)(2616005)(7596003)(956004)(5660300002)(86362001)(47076004)(31696002)(53546011)(77540400001)(26005)(316002)(82740400003)(786003)(8676002)(36906005)(75432002)(478600001)(356005)(31686004)(2906002)(186003)(4744005)(82310400002)(8936002)(110136005)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ac0a67e-2559-4e86-50f9-08d81136911d X-MS-TrafficTypeDiagnostic: MN2PR12MB3152: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04359FAD81 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eoXQuTVnH/fsk4HLRASOEC42iI7IoV1nDVyhnAbUAEzUnqVSg26ESWC4+Hi+SmHoHYSgaJriNPinV375nQ8QuS2lBfYpcpOkBQ2Q68FqtMwui3dNUYLaUHisxxJcVwP7QwZtA8ZIvdhz2P09rYrjSd9NfQnrnmriiNP7VtEcNHCvYu9LMimgUGgzIY9seLRZG4HgXEa2DJsoCSNCQaKNtvAeJpdRp3cY3rcCH6+pQ+YtvQsiY5MsBFAYvCrPx2ROD27bgql+wJWOTUVIbi910P/MV6ApSxL6nONlQMW1Ola5hml2aKIZTD2Se1G4g4gbwsRhYShx5DzJXIwRwPmpi3IaCjX0CZIp0ZS82Ae/t2gpjUAzAbrbH84pnbnfu56vUFFhrvUpOS/wT0XuVjD4vIZUwNkPu+EbzXkbLtMnfaA1Vobl+/reZkWwEO9wj0+9 X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 14:15:33.1349 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ac0a67e-2559-4e86-50f9-08d81136911d X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3152 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 14:15:36 -0000 On 6/13/20 6:00 PM, Russ Penar wrote: > Hi Paul, Thanks for the feedback, this is great! ... > *Section 3.4 - The more I think about this, the less I think we should involve any announcement at all. Given there's really no failure in this scenario (if there were, a 607 or 608 would be used), call either is not answered or goes to voice mail. I just need to provide a signal back hinting as to why the call went unanswered. If you are rethinking that, then I think it is appropriate to step back and have a high level discussion of what the problem is, and then how best to remedy that. Thanks, Paul From nobody Mon Jun 15 08:10:18 2020 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 62F703A0E5A for ; Mon, 15 Jun 2020 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sippysoft.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 8ST5DEwHMScw for ; Mon, 15 Jun 2020 08:10:14 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 E481E3A0E3F for ; Mon, 15 Jun 2020 08:09:28 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id x93so11778449ede.9 for ; Mon, 15 Jun 2020 08:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Afb/5SpRw8fPzE9ip+dyugXiQo9KLsBqA+TpSdxGkYk=; b=z/PJb3dnuM/ICDznVpr4RrJmhgBU41EloibI4NHkvcQ3T/dSHwVlfmpcaRJjmQDTda UbrHQuRtcRZICX6xkzurZm4MHqXaXNbNIXsfKziOo9/Z6VLKFi7ZEJdacOAUAfFHW8iY /RAuE43PcoesRAenSwdIpBE5pAMO0sbpUzjMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Afb/5SpRw8fPzE9ip+dyugXiQo9KLsBqA+TpSdxGkYk=; b=TT/qeHZCS2lZtfE23P+d73UxajnmDraAwn6c03yQe3Dd8brQ1MMn+PDcBCvC/jI5/x 94HDHPjzb74avSBCi1G5NboTVEqMlSYszUNbkh/yYLAj0UN2TkCDOLydtNzkd8vy0Ibf prKYRyGhlVU5EHZzfD9/t/taLgZDnF1Wc1WmRdbK2Vs2rOW59iyb/FIeDLeB07eIb0bJ u7EKR7tAktodTAjav0a7FVJbmj6uppmGEfF3Gfd7no32iB7j2UkIQmeeZGCXvq2LtvNX 5sBJlieRIPfd4YDsn3Q2uYcgNVNUnGd9wsK2sh/3bakw/wxAQPEe7YnohRY2J0MSJIls fChg== X-Gm-Message-State: AOAM533J0LNAiHphQOAbmaViEkFyd6oqUF5GZgw2+gICnoKVlW7lBLp5 cc31+nbCltEonX4bxOShdbBPday999O01pgS1Ct1HaUZ X-Google-Smtp-Source: ABdhPJxsQz+2cbNcap2NzOS1zzuDyAN/lYVYcjFaI9Et3QKSxunYPup0O9fjIpz43ZJLV4MSDOA6q5a+rRMVRekeSBY= X-Received: by 2002:aa7:d9d3:: with SMTP id v19mr23517366eds.364.1592233767133; Mon, 15 Jun 2020 08:09:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Maxim Sobolev Date: Mon, 15 Jun 2020 08:09:15 -0700 Message-ID: To: Russ Penar Cc: sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000173c6005a820d0d3" Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 15:10:16 -0000 --000000000000173c6005a820d0d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For what it's worth, I think the proposed solution is too heavyweight. Allocating a new status code just for this particular task seems like an overkill. Simple header included into 18x provisional response should do the trick in 99% of practical cases. Let's not forget that in a presence of PRACK provisional responses need end-to-end confirmation and RFC specifically prohibits UAS from issuing a next response until the previous one has been acknowledged (or PRACK times out). Otherwise I would say we need a general new status response code class, where this would be just one of many possible uses. I'd also say < 180 code is more suitable, since such a check would logically be done before "alerting" starts. -Max On Fri., Jun. 12, 2020, 2:55 p.m. Russ Penar, wrote: > Hi All, > > Please take a look at my proposed draft regarding a 1xx message letting > caller know their call is rated poorly/ambiguously. > > One early feedback is 184 may be too close to progress messages associate= d > with ringback, and I=E2=80=99d love to get more perspectives. > > https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ > > Best regards, > > Russ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000173c6005a820d0d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth, I think the proposed solution is= too heavyweight. Allocating a new status code just for this particular tas= k seems like an overkill. Simple header included into 18x provisional respo= nse should do the trick in 99% of practical cases. Let's not forget tha= t in a presence of PRACK provisional responses need end-to-end confirmation= and RFC specifically prohibits UAS from issuing a next response until the = previous one has been acknowledged (or PRACK times out).
<= br>
Otherwise I would say we need a general new stat= us response code class, where this would be just one of many possible uses.= I'd also say < 180 code is more suitable, since such a check would = logically be done before "alerting" starts.
=
-Max

On Fri., Jun. 12, 2020, 2:55 p.= m. Russ Penar, <russp=3D40microsoft.com@dmarc.ietf.org> wrote:

Hi All,

Please take a look at my= proposed draft regarding a 1xx message letting caller know their call is r= ated poorly/ambiguously.

One early feedback is 18= 4 may be too close to progress messages associated with ringback, and I=E2= =80=99d love to get more perspectives.

https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/

Best regards,

Russ

_______________________________________________
sipcore mailing list
si= pcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcor= e
--000000000000173c6005a820d0d3-- From nobody Mon Jun 15 08:20:46 2020 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 E2DC83A0D0E for ; Mon, 15 Jun 2020 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 7BMQGOE3mjet for ; Mon, 15 Jun 2020 08:20:44 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650092.outbound.protection.outlook.com [40.107.65.92]) (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 069903A0D03 for ; Mon, 15 Jun 2020 08:20:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T7ZuO8N2w7wLpQjAVCepSDThgUSZYJuT3L2WymcYqst7mot8BlwF6lXhEOGlhWMYMgRSyKKaGWGmSvdkeCDDaJvf3hKexTXuxT5u4WxmLVw5sbWxIjGW9g4UXBP+XgaIce+Wcqahrs5j9JlvfdXWmpIhC/2eyK3JkOroNJp1Ef7BxqnH7oec6W70qCd2pWb2a8Gohqux9CeH3AoYR09sicsYfcC7IB6LabqSLAigxP25+fSD2XbSSEYI9dC1b+OD3uPIok9JQhOBJ7GC7CVtQvSZ/33nfyf+O6YF8PUNTPEgnu0k/vnuOPoiy9aBq4kxe0CDWWYWOAtOKPp2cfn7ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ya+Ku0iOTzLD7H3wFVmmRAfkkGGPOg0l97CKGuJzG8=; b=fTJnQhNSl9tniGjiz2yMxv93Hw4FNmIm+GNkvZ+wy+wPGy3cddLYx+R5rFeeAZf/4eyK/W5ARS9R0kQLx6C6KhHgp6BVKCOhfyr5+5mU0whSlVfOjj7OV0YMzKQP5gH5mLirDBicv4hLTBV9Gvajakpn35GFfuNw5Xso6XosytxnNspNQ+MkiWFYB6baYomRGuG13iUJGCCdVQzkmVUQIU1i3juLKMrUH5oKGJP1yq/v4hemP8P3IGXPoGakvjZpY0Yj+9CIxRkJrbIVsWlUDG5AQaoNzrBocXNS31PmFldvqBg9fTZ4EySo2yLR1M2JeTcTPnewzIjCAGrW0UASHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ya+Ku0iOTzLD7H3wFVmmRAfkkGGPOg0l97CKGuJzG8=; b=WM8RO0C/MpgmuEWazIoHP9qfPuZTcphQgCdc+gIhOV76h10PDSBEFBpAJHpDrzRpyXic49PJqADIrTqmQnjqk8Xxlnu/EL41yEQIMm0RJbbpZri/wsjpQFnmiQM3T/j78fLyk9L7bjxI4J/fqti70rJZcFbfuGH++o0XVV6JtdQ= Received: from DM5PR00MB0423.namprd00.prod.outlook.com (2603:10b6:4:a0::35) by DM5PR00MB0265.namprd00.prod.outlook.com (2603:10b6:3:2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3136.0; Mon, 15 Jun 2020 15:20:39 +0000 Received: from DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151]) by DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151%6]) with mapi id 15.20.3143.000; Mon, 15 Jun 2020 15:20:39 +0000 From: Russ Penar To: Maxim Sobolev CC: "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore Thread-Index: AdZBBAfA3uPUg+ERQ5G4Wnos9BXr1wCIucmAAAAgHFA= Date: Mon, 15 Jun 2020 15:20:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e3bffe6b-ffdf-433d-bf85-0000594af302; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-15T15:12:51Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: sippysoft.com; dkim=none (message not signed) header.d=none;sippysoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0e3ced5b-e4b2-457e-bb8f-08d8113fa9a0 x-ms-traffictypediagnostic: DM5PR00MB0265: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +SzGUAks8HG6HSRWgA93Lam/lsmEIt99OyrGVn7r83D7z3zzmHibVJ0FPDA1zuKsORV7sx7sI/DaD1Ts0MrbI9CCo9GyvlnZNwRuWpLNLM5ZncuEehVNrz3rqeSgxbo+SfjYsLcXYQ0doY5aW/woNDilmoyNIJ5ZJF4M1agLKM8WuL5NO727TJ1y+16VyZlcsaHBUNkKPRbOTJEysW2hsGs5WYCYmwe2WH7CwoWcmj2MBAJCEAXdhyOjfz5ggZTub3/zMNA3hdp9rTUKv4200+BpyZNq6tcFoxRO6AxkbfI4Rq8hVj0PNLE195jGrGA2v7ha3H8fFiRWzAxMLIKkpxPgmEPWcCNEau47x3Xszl+VdMMvj1hqfG8hxGddlkQkjV0Nl92R5ZLZsv4Z4wSm2g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0423.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(396003)(376002)(136003)(186003)(8990500004)(26005)(8936002)(6506007)(7696005)(8676002)(52536014)(53546011)(83380400001)(2906002)(966005)(316002)(82950400001)(55016002)(86362001)(33656002)(82960400001)(5660300002)(66446008)(66946007)(64756008)(10290500003)(4326008)(71200400001)(66556008)(76116006)(66476007)(166002)(478600001)(9686003)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TkDQ1cdrOspKiV1m+2jP7g2lKr5mrsPrso72fPSFYAHnghbuwolwqcLyU88txH5/fdpmNzG92ILOAVYSDmIvAu0Nf9pK09K1Cq4/XJ5t06B2BSqkj2IV3MVR4J3LBWBte9fQAcEqSocxaWin+8jLzFH1i7Ty6bgwxWUgrt7VM+iXja1ajvj8jdeh8ZWihBc1uLn5+zBf7jQ8kYWGe6Gv+nFP7yaKsQmkNwtuYjmxvjBB7l0dJZzgYhULoYHlYposER5y6Dbfjlutu9Q2V4t651RJo8ab2e3ME2q5KpMujzfWWELMwBN2YWWY0wRXk/xMvRKXnnPSyZXH8zstuVJCxAXvWsmKBLdBBN+EFj41fgBhff9lOmWq5NBf7n/Dm7bhn9+sLCXh5aXrfibHVKLkBp38XmK/+F3lBhUDOld/BvSdOsodxrWHeJaNME6YmxrheeHxJJrCCiHPyxKrtpqHt5cr6PJzTBFySNTgSaZbtwA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0423F1D8B559E5EF97612753B69C0DM5PR00MB0423namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0423.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e3ced5b-e4b2-457e-bb8f-08d8113fa9a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 15:20:39.7951 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5lsSCRrL5ADr42w+EUW8HxRYa9L+WdboNpiPtRwdQica+S2dug5Ms78m08xPHCRXJr+A/QpNiBLehtWPv+7YzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0265 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 15:20:46 -0000 --_000_DM5PR00MB0423F1D8B559E5EF97612753B69C0DM5PR00MB0423namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IE1heCENCg0KVW5kZXJzdG9vZCBvbiBoZWF2eXdlaWdodCwgYnV0IGJlbGlldmUg aXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBwcm92aWRlIGEgY2FsbCByYXRpbmcgc2lnbmFsIChhcyBr bm93biBmcm9tIHRoZSBuZXR3b3JrKSBzZXBhcmF0ZSBmcm9tIGFsZXJ0aW5nIG1lc3NhZ2VzLCBh bmQgSeKAmW0gd2FyeSBvZiByZS11c2luZyBUcnlpbmcuICBJ4oCZbSBvcGVuIHRvIHRoZSBpZGVh IG9mIGEgbmV3IGNvZGUgY2xhc3MgaWYgdGhhdCBtYWtlcyB0aGUgbW9zdCBzZW5zZSB0byB0aGUg Z3JvdXAuDQoNCkNvbXBsZXRlbHkgYWdyZWUgb24gdGhlIDwxODAsIHRoYXQgd2FzIGVhcmx5IGZl ZWRiYWNrIGZyb20gU2hyZXlhcyBhbmQgY29ycmVjdGVkIGluIHRoZSBiZXR0ZXIgbmFtZWQvZm9y bWF0dGVkIGRyYWZ0IHByb3Bvc2FsIHBlciBmZWVkYmFjayBmcm9tIEJyaWFuLCBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5hci1zaXBjb3JlLXJhdGluZ3Byb3ZpZGVk Lw0KDQpJ4oCZbSBtZWV0aW5nIHRoaXMgd2VlayB0byBkaXNjdXNzIG9wcG9ydHVuaXR5IHRvIGpv aW4gZm9yY2VzIHdpdGggb3RoZXJzIGluIHRoZSBXRyBhbmQgcGVyaGFwcyBjb25zb2xpZGF0ZSB0 aGUgd29ya2luZyBwcm9wb3NhbCwgYnV0IGJlbGlldmUgZGlzY3Vzc2lvbiBvbiBjdXJyZW50IOKA mC4ucmF0aW5ncHJvdmlkZWTigJkgZHJhZnQgaXMgaGVscGZ1bCwgdGhhbmtzIGFnYWluIQ0KDQpG cm9tOiBNYXhpbSBTb2JvbGV2IDxzb2JvbWF4QHNpcHB5c29mdC5jb20+DQpTZW50OiBNb25kYXks IEp1bmUgMTUsIDIwMjAgODowOSBBTQ0KVG86IFJ1c3MgUGVuYXIgPHJ1c3NwQG1pY3Jvc29mdC5j b20+DQpDYzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW3NpcGNv cmVdIHBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZHJhZnQtcGVuYXItaWV0Zi1zaXBjb3Jl DQoNCkZvciB3aGF0IGl0J3Mgd29ydGgsIEkgdGhpbmsgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlz IHRvbyBoZWF2eXdlaWdodC4gQWxsb2NhdGluZyBhIG5ldyBzdGF0dXMgY29kZSBqdXN0IGZvciB0 aGlzIHBhcnRpY3VsYXIgdGFzayBzZWVtcyBsaWtlIGFuIG92ZXJraWxsLiBTaW1wbGUgaGVhZGVy IGluY2x1ZGVkIGludG8gMTh4IHByb3Zpc2lvbmFsIHJlc3BvbnNlIHNob3VsZCBkbyB0aGUgdHJp Y2sgaW4gOTklIG9mIHByYWN0aWNhbCBjYXNlcy4gTGV0J3Mgbm90IGZvcmdldCB0aGF0IGluIGEg cHJlc2VuY2Ugb2YgUFJBQ0sgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIG5lZWQgZW5kLXRvLWVuZCBj b25maXJtYXRpb24gYW5kIFJGQyBzcGVjaWZpY2FsbHkgcHJvaGliaXRzIFVBUyBmcm9tIGlzc3Vp bmcgYSBuZXh0IHJlc3BvbnNlIHVudGlsIHRoZSBwcmV2aW91cyBvbmUgaGFzIGJlZW4gYWNrbm93 bGVkZ2VkIChvciBQUkFDSyB0aW1lcyBvdXQpLg0KDQpPdGhlcndpc2UgSSB3b3VsZCBzYXkgd2Ug bmVlZCBhIGdlbmVyYWwgbmV3IHN0YXR1cyByZXNwb25zZSBjb2RlIGNsYXNzLCB3aGVyZSB0aGlz IHdvdWxkIGJlIGp1c3Qgb25lIG9mIG1hbnkgcG9zc2libGUgdXNlcy4gSSdkIGFsc28gc2F5IDwg MTgwIGNvZGUgaXMgbW9yZSBzdWl0YWJsZSwgc2luY2Ugc3VjaCBhIGNoZWNrIHdvdWxkIGxvZ2lj YWxseSBiZSBkb25lIGJlZm9yZSAiYWxlcnRpbmciIHN0YXJ0cy4NCg0KLU1heA0KDQpPbiBGcmku LCBKdW4uIDEyLCAyMDIwLCAyOjU1IHAubS4gUnVzcyBQZW5hciwgPHJ1c3NwPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn Pj4gd3JvdGU6DQpIaSBBbGwsDQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgbXkgcHJvcG9zZWQgZHJh ZnQgcmVnYXJkaW5nIGEgMXh4IG1lc3NhZ2UgbGV0dGluZyBjYWxsZXIga25vdyB0aGVpciBjYWxs IGlzIHJhdGVkIHBvb3JseS9hbWJpZ3VvdXNseS4NCk9uZSBlYXJseSBmZWVkYmFjayBpcyAxODQg bWF5IGJlIHRvbyBjbG9zZSB0byBwcm9ncmVzcyBtZXNzYWdlcyBhc3NvY2lhdGVkIHdpdGggcmlu Z2JhY2ssIGFuZCBJ4oCZZCBsb3ZlIHRvIGdldCBtb3JlIHBlcnNwZWN0aXZlcy4NCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbmFyLWlldGYtc2lwY29yZS88aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1wZW5hci1pZXRmLXNpcGNvcmUl MkYmZGF0YT0wMiU3QzAxJTdDcnVzc3AlNDBtaWNyb3NvZnQuY29tJTdDYmYxZmRkMzM1ZjQ2NDRi ZDRmMGYwOGQ4MTEzZTM4MWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzAl N0MwJTdDNjM3Mjc4MzA2MjE4MDEzMDkyJnNkYXRhPUJFZmZNNldsN1lEWWJtZUdMJTJGbXVDV0Zm a2xXRlNKa2JTWXJWcVFGVHAyTSUzRCZyZXNlcnZlZD0wPg0KQmVzdCByZWdhcmRzLA0KUnVzcw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpcGNvcmUmZGF0YT0wMiU3QzAxJTdD cnVzc3AlNDBtaWNyb3NvZnQuY29tJTdDYmYxZmRkMzM1ZjQ2NDRiZDRmMGYwOGQ4MTEzZTM4MWYl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzAlN0MwJTdDNjM3Mjc4MzA2MjE4 MDEzMDkyJnNkYXRhPUNQdjVncGhjTXBSM3BjaXNmSE5kdlpqQWE0c0U3WjZtdlJIMm1SdDl2RjAl M0QmcmVzZXJ2ZWQ9MD4NCg== --_000_DM5PR00MB0423F1D8B559E5EF97612753B69C0DM5PR00MB0423namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rIHlvdSBNYXghPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuZGVyc3Rvb2Qgb24g aGVhdnl3ZWlnaHQsIGJ1dCBiZWxpZXZlIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSBh IGNhbGwgcmF0aW5nIHNpZ25hbCAoYXMga25vd24gZnJvbSB0aGUgbmV0d29yaykgc2VwYXJhdGUg ZnJvbSBhbGVydGluZyBtZXNzYWdlcywgYW5kIEnigJltIHdhcnkgb2YgcmUtdXNpbmcgVHJ5aW5n LiZuYnNwOyBJ4oCZbSBvcGVuIHRvIHRoZSBpZGVhIG9mIGEgbmV3IGNvZGUgY2xhc3MgaWYgdGhh dCBtYWtlcw0KIHRoZSBtb3N0IHNlbnNlIHRvIHRoZSBncm91cC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q29tcGxldGVseSBhZ3JlZSBvbiB0aGUgJmx0OzE4MCwgdGhhdCB3YXMgZWFybHkgZmVl ZGJhY2sgZnJvbSBTaHJleWFzIGFuZCBjb3JyZWN0ZWQgaW4gdGhlIGJldHRlciBuYW1lZC9mb3Jt YXR0ZWQgZHJhZnQgcHJvcG9zYWwgcGVyIGZlZWRiYWNrIGZyb20gQnJpYW4sDQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5hci1zaXBjb3JlLXJhdGlu Z3Byb3ZpZGVkLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVuYXIt c2lwY29yZS1yYXRpbmdwcm92aWRlZC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlt IG1lZXRpbmcgdGhpcyB3ZWVrIHRvIGRpc2N1c3Mgb3Bwb3J0dW5pdHkgdG8gam9pbiBmb3JjZXMg d2l0aCBvdGhlcnMgaW4gdGhlIFdHIGFuZCBwZXJoYXBzIGNvbnNvbGlkYXRlIHRoZSB3b3JraW5n IHByb3Bvc2FsLCBidXQgYmVsaWV2ZSBkaXNjdXNzaW9uIG9uIGN1cnJlbnQg4oCYLi5yYXRpbmdw cm92aWRlZOKAmSBkcmFmdCBpcyBoZWxwZnVsLCB0aGFua3MgYWdhaW4hDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1heGlt IFNvYm9sZXYgJmx0O3NvYm9tYXhAc2lwcHlzb2Z0LmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgSnVuZSAxNSwgMjAyMCA4OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBSdXNzIFBlbmFy ICZsdDtydXNzcEBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2lwY29yZUBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbc2lwY29yZV0gcGxlYXNl IHJldmlldyBhbmQgY29tbWVudCBvbiBkcmFmdC1wZW5hci1pZXRmLXNpcGNvcmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHdoYXQgaXQncyB3b3J0aCwgSSB0aGlu ayB0aGUgcHJvcG9zZWQgc29sdXRpb24gaXMgdG9vIGhlYXZ5d2VpZ2h0LiBBbGxvY2F0aW5nIGEg bmV3IHN0YXR1cyBjb2RlIGp1c3QgZm9yIHRoaXMgcGFydGljdWxhciB0YXNrIHNlZW1zIGxpa2Ug YW4gb3ZlcmtpbGwuIFNpbXBsZSBoZWFkZXIgaW5jbHVkZWQgaW50byAxOHggcHJvdmlzaW9uYWwg cmVzcG9uc2Ugc2hvdWxkIGRvIHRoZSB0cmljayBpbiA5OSUgb2YNCiBwcmFjdGljYWwgY2FzZXMu IExldCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBhIHByZXNlbmNlIG9mIFBSQUNLIHByb3Zpc2lvbmFs IHJlc3BvbnNlcyBuZWVkIGVuZC10by1lbmQgY29uZmlybWF0aW9uIGFuZCBSRkMgc3BlY2lmaWNh bGx5IHByb2hpYml0cyBVQVMgZnJvbSBpc3N1aW5nIGEgbmV4dCByZXNwb25zZSB1bnRpbCB0aGUg cHJldmlvdXMgb25lIGhhcyBiZWVuIGFja25vd2xlZGdlZCAob3IgUFJBQ0sgdGltZXMgb3V0KS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk90aGVyd2lzZSBJ IHdvdWxkIHNheSB3ZSBuZWVkIGEgZ2VuZXJhbCBuZXcgc3RhdHVzIHJlc3BvbnNlIGNvZGUgY2xh c3MsIHdoZXJlIHRoaXMgd291bGQgYmUganVzdCBvbmUgb2YgbWFueSBwb3NzaWJsZSB1c2VzLiBJ J2QgYWxzbyBzYXkgJmx0OyAxODAgY29kZSBpcyBtb3JlIHN1aXRhYmxlLCBzaW5jZSBzdWNoIGEg Y2hlY2sgd291bGQgbG9naWNhbGx5IGJlIGRvbmUgYmVmb3JlICZxdW90O2FsZXJ0aW5nJnF1b3Q7 IHN0YXJ0cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1N YXg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmkuLCBKdW4uIDEyLCAyMDIwLCAyOjU1IHAubS4gUnVzcyBQZW5hciwgJmx0 O3J1c3NwPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPjQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgQWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QbGVh c2UgdGFrZSBhIGxvb2sgYXQgbXkgcHJvcG9zZWQgZHJhZnQgcmVnYXJkaW5nIGEgMXh4IG1lc3Nh Z2UgbGV0dGluZyBjYWxsZXIga25vdyB0aGVpciBjYWxsIGlzIHJhdGVkIHBvb3JseS9hbWJpZ3Vv dXNseS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PbmUgZWFybHkgZmVlZGJhY2sgaXMgMTg0IG1heSBiZSB0 b28gY2xvc2UgdG8gcHJvZ3Jlc3MgbWVzc2FnZXMgYXNzb2NpYXRlZCB3aXRoIHJpbmdiYWNrLCBh bmQgSeKAmWQgbG92ZSB0byBnZXQgbW9yZSBwZXJzcGVjdGl2ZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxh IGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtcGVuYXIt aWV0Zi1zaXBjb3JlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NydXNzcCU0MG1pY3Jvc29mdC5jb20l N0NiZjFmZGQzMzVmNDY0NGJkNGYwZjA4ZDgxMTNlMzgxZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMCU3QzAlN0M2MzcyNzgzMDYyMTgwMTMwOTImYW1wO3NkYXRhPUJFZmZN NldsN1lEWWJtZUdMJTJGbXVDV0Zma2xXRlNKa2JTWXJWcVFGVHAyTSUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXBlbmFyLWlldGYtc2lwY29yZS88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpcGNvcmUm YW1wO2RhdGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3Q2JmMWZkZDMzNWY0NjQ0 YmQ0ZjBmMDhkODExM2UzODFmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mw JTdDMCU3QzYzNzI3ODMwNjIxODAxMzA5MiZhbXA7c2RhdGE9Q1B2NWdwaGNNcFIzcGNpc2ZITmR2 WmpBYTRzRTdaNm12UkgybVJ0OXZGMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_DM5PR00MB0423F1D8B559E5EF97612753B69C0DM5PR00MB0423namp_-- From nobody Mon Jun 15 08:25:48 2020 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 134763A0D03 for ; Mon, 15 Jun 2020 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 RkpFbgjmXIiu for ; Mon, 15 Jun 2020 08:25:45 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 8FE793A082F for ; Mon, 15 Jun 2020 08:25:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RQyg+EFgUk/y40G3C4c3L9IpHLMBn77cV9ijcRM3NRFJ4pPbaJr4dDROYe48FgaHQ9u8uiC97GSftSfrKsg1yv+bTVuAvmk97TG7AwsdtnM4sJ5t+aauhIrEQ0xhfRYtFSUW7bu6sNhfs3+ikLtfXz3cVBYGt9pIw7sE00vnOnBbKggEAydCaN0LRu0zhJskBn2zuFxpfF2KGfYXPSuhvKgJbKfFEv8hmj0YFhEWSPovmwbyWE5185492wUOJARkpm5KM/VOonL7UBGbQbPfg9iakHXcYjrBrzVl8UvhvKorBVVfKOOM0mBYcCP4BAvDjg8F0BGIlUd5PXZ+k6kbzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OskO6Zypd7yrrvCtIXrcKDYCvUfdhAM52q0uUNKgQSY=; b=ZiAmGpeEyYyDJmSBlYMiodbKIO1UnwjB/DXa6p5r0Dz9F0vmoyoTx10iQKEFTI3AlOswgjgCSUdBRDD05QhbqKmhKhCWGUTOnLQZMiqF6JH0e0+oK+smuBBTJJ6I/vCrShpL4yAKrvp7ywUiSXkhktg6oydShlXT+ArQY8oX0KdFq9tfaAlx7D+VutAycLgPWy4BzEuZOkeSWoj8nVf7heQi2JfYIFDBkAa6ejFxNHc++NSOJvfjG3LdcMdu/GoGI1tvIfmrEZ3O8vWXcFJ0wSesCTb8ZnsDtUQ6mEHwdCHsAJYDCxkA/sMiWmj2+Lp09Ga5kU7AUNTPMuKLetDh9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OskO6Zypd7yrrvCtIXrcKDYCvUfdhAM52q0uUNKgQSY=; b=KZycPIpBszuAGK9/YqFLqEc3LBht3pgXuzMBc38s8JKijvJvcPRVz7si26VW3eOA7O7b6Hxvcv2bi7iJXD3+WssOl86uEPmkxjU3mm2W3SnhysBnCeKw3oPFOeIVv8bTwQer35YCUgOzXkbQnKecHNnlxH287x2OFH+DxLRkGU8= Received: from DM5PR00MB0423.namprd00.prod.outlook.com (2603:10b6:4:a0::35) by DM6PR00MB0846.namprd00.prod.outlook.com (2603:10b6:5:1b5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3143.0; Mon, 15 Jun 2020 15:25:44 +0000 Received: from DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151]) by DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::e1cf:72da:5f8c:d151%6]) with mapi id 15.20.3143.000; Mon, 15 Jun 2020 15:25:44 +0000 From: Russ Penar To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore Thread-Index: AdZBBAfA3uPUg+ERQ5G4Wnos9BXr1wAuhJCAAAMDynAAVVEGgAACT4/A Date: Mon, 15 Jun 2020 15:25:43 +0000 Message-ID: References: <20d07be6-111a-d98c-702d-6880f0e332ad@alum.mit.edu> <44ef1efd-6446-7f03-8c25-f7a04579ac90@alum.mit.edu> In-Reply-To: <44ef1efd-6446-7f03-8c25-f7a04579ac90@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=22b9d157-f884-47e1-803a-000010051ea7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-15T15:21:41Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none; alum.mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70a5c499-6015-425e-ac82-08d811405edf x-ms-traffictypediagnostic: DM6PR00MB0846: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: L4r/joJ3qRy1wE9XscXnhChpDgS0122G+ibEt5mSKSTR3V+yk6XR9HquHDIk8kODLxaSskM5c3hGa6o/RRE2yrzqZQZoblX5ysdDHlP8nK7msM25LclAUUfhueFdYilyRc8UrKCMzCvWxQWZRrgX1vzIFthS0yshvtka2V4ua2ECf+EOU8p7ilmTK+wZyfKCesXHUKYj8jlbVOyW3Z6YlRm3fdCs6wva8Vvoh0Bdgryt0eQHaQ93BhIyFspfke2lcRdoO+sx38nIB7DIPFSmqalBvyLA9q/VZDM6Sx+UTK6CxTQpnE0xRZYzOx0k9nabRDju+hnY7jk/fN5L1OywLw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0423.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(136003)(376002)(346002)(478600001)(186003)(110136005)(77540400001)(33656002)(316002)(66946007)(66476007)(64756008)(66446008)(76116006)(10290500003)(71200400001)(83380400001)(66556008)(8990500004)(8676002)(53546011)(9686003)(8936002)(55016002)(6506007)(7696005)(86362001)(82950400001)(82960400001)(52536014)(2906002)(4744005)(26005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /IYGXyl3gUf/smImwL/23bkAzZTk6JpI6Eqlc9Fb+OuWGzlW9bgmgvkJUqLi6ie05J+/8N+WbzdhGotj8LbPlVrAqut/K4UHt8jyG84pPJHBLOHgYmQtNEICQLIPMsEGJyuSy9XauO9pHmj88+82aLyMO4FyfyOCeTlZjYVzt/k2smMrjiKz98ogPZvNnRxIoITUFFE6mSFYKGx/YKrnyOpFtCkt5vevjM2mSheH5HQvXZAWo+w0lIhUoQWub14EuqYoDrzeb1U00SbXkbRJ1KjPpchnsiEWtlcaVFYPChXwBbZONU5dw2FbdIwYrXJN72d/XvO5VIlzzvmZ7df1C77Cjceo0aL5R8VxrWMwowGaUztdHQfpuxSLckdCGThTENB6YXLNLoMw/0FgPWG89HSpDmTWqZM4o6iDyPyssICSEjZNaG/EB+zq0Ivk6rRaQ64xCi69dn9yoSlfu6MFAbgr89FhA06Pq1/FwISyk7o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0423.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70a5c499-6015-425e-ac82-08d811405edf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 15:25:43.8772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ILyUU5Afpi2mMdt26pwEzucJXMRlJGAZfdNklE+lKiSXZjnXARi94kuiJr1NU4Hg+wxkadmUJPcUe+4dQkEbHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0846 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 15:25:47 -0000 TWFrZXMgc2Vuc2UsIHRoYW5rcyBQYXVsLiAgDQpJJ20gbWVldGluZyB3aXRoIGEgY291cGxlIGZv bGtzIGZyb20gdGhlIFdHIHRvIGhhdmUgc3VjaCBhIGRpc2N1c3Npb24gdGhpcyB3ZWVrLg0KTWF4 J3Mgc3VnZ2VzdGlvbiBvZiBhIG5ldyBjb2RlIGNsYXNzIGlzIGludGVyZXN0aW5nLiANCg0KQmVz dCByZWdhcmRzLA0KUnVzcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1 bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IA0KU2VudDogTW9uZGF5LCBKdW5lIDE1 LCAyMDIwIDc6MTYgQU0NClRvOiBSdXNzIFBlbmFyIDxydXNzcEBtaWNyb3NvZnQuY29tPjsgc2lw Y29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFWFRFUk5BTF0gUmU6IFtzaXBjb3JlXSBwbGVh c2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIGRyYWZ0LXBlbmFyLWlldGYtc2lwY29yZQ0KDQpPbiA2 LzEzLzIwIDY6MDAgUE0sIFJ1c3MgUGVuYXIgd3JvdGU6DQo+IEhpIFBhdWwsICBUaGFua3MgZm9y IHRoZSBmZWVkYmFjaywgdGhpcyBpcyBncmVhdCENCi4uLg0KPiAqU2VjdGlvbiAzLjQgLSBUaGUg bW9yZSBJIHRoaW5rIGFib3V0IHRoaXMsIHRoZSBsZXNzIEkgdGhpbmsgd2Ugc2hvdWxkIGludm9s dmUgYW55IGFubm91bmNlbWVudCBhdCBhbGwuIEdpdmVuIHRoZXJlJ3MgcmVhbGx5IG5vIGZhaWx1 cmUgaW4gdGhpcyBzY2VuYXJpbyAoaWYgdGhlcmUgd2VyZSwgYSA2MDcgb3IgNjA4IHdvdWxkIGJl IHVzZWQpLCBjYWxsIGVpdGhlciBpcyBub3QgYW5zd2VyZWQgb3IgZ29lcyB0byB2b2ljZSBtYWls LiAgSSBqdXN0IG5lZWQgdG8gcHJvdmlkZSBhIHNpZ25hbCBiYWNrIGhpbnRpbmcgYXMgdG8gd2h5 IHRoZSBjYWxsIHdlbnQgdW5hbnN3ZXJlZC4NCg0KSWYgeW91IGFyZSByZXRoaW5raW5nIHRoYXQs IHRoZW4gSSB0aGluayBpdCBpcyBhcHByb3ByaWF0ZSB0byBzdGVwIGJhY2sgYW5kIGhhdmUgYSBo aWdoIGxldmVsIGRpc2N1c3Npb24gb2Ygd2hhdCB0aGUgcHJvYmxlbSBpcywgYW5kIHRoZW4gaG93 IGJlc3QgdG8gcmVtZWR5IHRoYXQuDQoNCglUaGFua3MsDQoJUGF1bA0K From nobody Mon Jun 15 09:11:47 2020 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 8500B3A0E7F for ; Mon, 15 Jun 2020 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sippysoft.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 0ZqQNbMy7_Y8 for ; Mon, 15 Jun 2020 09:11:43 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 77C0B3A0E7A for ; Mon, 15 Jun 2020 09:11:43 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id x1so18044403ejd.8 for ; Mon, 15 Jun 2020 09:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbcKHzhgjO/jBCnIGwQItrNBrcDWeMqjpwDVZWJaqb4=; b=GikuPoUkO7EKZxqh27IafNA8CNOjA4xw33vTC6LXGa23RmmBUtPFrCjKucriT7EZJJ zeToAqGxRwnXU9wTYt8nzj7Z70nvHWeeTMB59Irpo0fxczCQkDezqIp5lvN+MTYShArJ Mji/6FM/X3AvO4dZpNGvTQcJQs4kl05Q4/ll8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rbcKHzhgjO/jBCnIGwQItrNBrcDWeMqjpwDVZWJaqb4=; b=RNr4O1RD+mADOfhv1hqdbcIoCexsjdob9hTchXZoUg8nru4jvE0905iPT2hyKt1R4h A2kTANfYDQAu2SV5JzU6jZNKRiMMdA6gIaQBsRT+NuErCAkYc0Ig3y2EAQqLeYPCbLiP boiaZvvNpsnf6SHEN0SSlD6MIjj4PSJTYnLhDhM++4rcmYsgn/EipdW1UxGR+JtRU9Sr IefZxJR+ij4XqQfuVsCzCJxOXAORH4qck9LCCa5QBRQ+/wCf7bWOwfKGOyatGeXceGMv V0t5vJ5zy8EMiUdi9+ARcReEwYMlqVdLkxMQFJZ1PAKC7QPbAEwKp277FQWrWuJ7H0gT 5zdw== X-Gm-Message-State: AOAM531mfaf+EUIijO4kq7nvJl3xDJg1d0uuIrCfv3PQXaUHf7gH0CjG 1sgaT8HxIK2CBPrFKUSu80gf5Wyqu61mmET/VAb6sQ== X-Google-Smtp-Source: ABdhPJwATy92apu5ICjTcZrt7/6AW6GJskwkWZTBdoj+k02Fo+xNX1ck59pNR02lLQhOXXvWSm16dK0/FX4GSKG8rXQ= X-Received: by 2002:a17:906:af84:: with SMTP id mj4mr25231880ejb.473.1592237501923; Mon, 15 Jun 2020 09:11:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Maxim Sobolev Date: Mon, 15 Jun 2020 09:11:30 -0700 Message-ID: To: Russ Penar Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3628205a821ae82" Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 16:11:46 -0000 --000000000000b3628205a821ae82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for understanding, Russ! I look forward to seeing the updated draft. WRT re-using "100 Trying" I think that is not going to fly, since in most cases, except very simple one (i.e. stateless proxy) 100 Trying is hop-by-hop, not end-to-end. -Max On Mon, Jun 15, 2020 at 8:20 AM Russ Penar wrote: > Thank you Max! > > > > Understood on heavyweight, but believe it may be necessary to provide a > call rating signal (as known from the network) separate from alerting > messages, and I=E2=80=99m wary of re-using Trying. I=E2=80=99m open to t= he idea of a new > code class if that makes the most sense to the group. > > > > Completely agree on the <180, that was early feedback from Shreyas and > corrected in the better named/formatted draft proposal per feedback from > Brian, > https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ > > > > I=E2=80=99m meeting this week to discuss opportunity to join forces with = others in > the WG and perhaps consolidate the working proposal, but believe discussi= on > on current =E2=80=98..ratingprovided=E2=80=99 draft is helpful, thanks ag= ain! > > > > *From:* Maxim Sobolev > *Sent:* Monday, June 15, 2020 8:09 AM > *To:* Russ Penar > *Cc:* sipcore@ietf.org > *Subject:* [EXTERNAL] Re: [sipcore] please review and comment on > draft-penar-ietf-sipcore > > > > For what it's worth, I think the proposed solution is too heavyweight. > Allocating a new status code just for this particular task seems like an > overkill. Simple header included into 18x provisional response should do > the trick in 99% of practical cases. Let's not forget that in a presence = of > PRACK provisional responses need end-to-end confirmation and RFC > specifically prohibits UAS from issuing a next response until the previou= s > one has been acknowledged (or PRACK times out). > > > > Otherwise I would say we need a general new status response code class, > where this would be just one of many possible uses. I'd also say < 180 co= de > is more suitable, since such a check would logically be done before > "alerting" starts. > > > > -Max > > > > On Fri., Jun. 12, 2020, 2:55 p.m. Russ Penar, 40microsoft.com@dmarc.ietf.org> wrote: > > Hi All, > > Please take a look at my proposed draft regarding a 1xx message letting > caller know their call is rated poorly/ambiguously. > > One early feedback is 184 may be too close to progress messages associate= d > with ringback, and I=E2=80=99d love to get more perspectives. > > https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ > > > Best regards, > > Russ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000b3628205a821ae82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for understanding, Russ! I look fo= rward to seeing the updated draft. WRT re-using "100 Trying" I th= ink that is not going to fly, since in most cases, except very simple one (= i.e. stateless proxy) 100 Trying is hop-by-hop, not end-to-end.

-Max

On Mon, Jun 15, 2020 at 8:20 AM Russ Penar <russp@microsoft.com> wrote:

Thank you Max!

=C2=A0

Understood on heavyweight, but believe it may be nec= essary to provide a call rating signal (as known from the network) separate= from alerting messages, and I=E2=80=99m wary of re-using Trying.=C2=A0 I= =E2=80=99m open to the idea of a new code class if that makes the most sense to the group.

=C2=A0

Completely agree on the <180, that was early feed= back from Shreyas and corrected in the better named/formatted draft proposa= l per feedback from Brian, https://datatracker.ietf.org/doc/draft-penar-sipcor= e-ratingprovided/

=C2=A0

I=E2=80=99m meeting this week to discuss opportunity= to join forces with others in the WG and perhaps consolidate the working p= roposal, but believe discussion on current =E2=80=98..ratingprovided=E2=80= =99 draft is helpful, thanks again!

=C2=A0

From: Maxim Sobolev <sobomax@sippysoft.com>
Sent: Monday, June 15, 2020 8:09 AM
To: Russ Penar <russp@microsoft.com>
Cc: sipcore@ie= tf.org
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft= -penar-ietf-sipcore

=C2=A0

For what it's worth, I think the proposed soluti= on is too heavyweight. Allocating a new status code just for this particula= r task seems like an overkill. Simple header included into 18x provisional = response should do the trick in 99% of practical cases. Let's not forget that in a presence of PRACK provisio= nal responses need end-to-end confirmation and RFC specifically prohibits U= AS from issuing a next response until the previous one has been acknowledge= d (or PRACK times out).

=C2=A0

Otherwise I would say we need a general new status r= esponse code class, where this would be just one of many possible uses. I&#= 39;d also say < 180 code is more suitable, since such a check would logi= cally be done before "alerting" starts.

=C2=A0

-Max

=C2=A0

On Fri., Jun. 12, 2020, 2:55 p.m. Russ Penar, <ru= ssp=3D4= 0microsoft.com@dmarc.ietf.org> wrote:

Hi All,=

Please take a look at my= proposed draft regarding a 1xx message letting caller know their call is r= ated poorly/ambiguously.

One early feedback is 18= 4 may be too close to progress messages associated with ringback, and I=E2= =80=99d love to get more perspectives.

https://datatracker.ietf= .org/doc/draft-penar-ietf-sipcore/

Best regards,

Russ

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.iet= f.org/mailman/listinfo/sipcore



--000000000000b3628205a821ae82-- From nobody Mon Jun 15 18:24:10 2020 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 BCC113A0F58 for ; Mon, 15 Jun 2020 18:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 52PJEs5Qf832 for ; Mon, 15 Jun 2020 18:24:07 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E653A0F54 for ; Mon, 15 Jun 2020 18:24:07 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id l0JMjMCNnb02Al0KcjmRey; Tue, 16 Jun 2020 01:24:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1592270646; bh=Kv2J2FciQchA0f2fjQVrouoL338KNdFKR/PekEaJcUI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=NTO2ujZsy5y3JCnW2fB64Gn6Tf6Le9qEiawKP4huB/a+B9TEgvNsY+9Um7atjmBc0 uERxuYxFtTRwffhPwCl2gZ1LgQwAEqoHwEnPUkXFRqIPFFYQWWVB6kLBBVxrjf6u5j TOLINhRHVidi9O/ARmu4PBu6dN68HYA9X7POfNqG2O4hyBmAk9tbKLsCgwTLXrzoOv Syd1g2APLB0QNKlHsqO7/B7tONVY+regcrFm+QFaYK39zsN9KZEmCynnCOq4yuvIq7 MtCdHOBjvSejO00At06Hx7tI3MjPEv2KnwuXPbemXwUj9xNXCZTtkeP+raobKqbrZd FNacI+m6FWuUg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id l0KajGmpXX6Tll0Kbj1G6V; Tue, 16 Jun 2020 01:24:06 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit 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 05G1O4FR031454; Mon, 15 Jun 2020 21:24:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 05G1O4AS031451; Mon, 15 Jun 2020 21:24:04 -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: Maxim Sobolev Cc: russp=40microsoft.com@dmarc.ietf.org, sipcore@ietf.org In-Reply-To: (sobomax@sippysoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Jun 2020 21:24:03 -0400 Message-ID: <87zh934xcc.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 01:24:09 -0000 Maxim Sobolev writes: > [...] Simple header included into 18x provisional response should do > the trick in 99% of practical cases. [...] One alternative would be to attach this information to 183 Session Progress. 183 resembles 180, but it carries no semantics about alerting: 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. Dale From nobody Mon Jun 15 18:30:46 2020 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 2BF273A0F68 for ; Mon, 15 Jun 2020 18:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sippysoft.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 yQZ5Bam5CztN for ; Mon, 15 Jun 2020 18:30:44 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 3B84A3A101F for ; Mon, 15 Jun 2020 18:30:27 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id k8so13032564edq.4 for ; Mon, 15 Jun 2020 18:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zSVzlWFMvPeuCU4XSjVpKAQdQZgJSd2Hp7k5EYAOpiw=; b=vJDsqJnUVu9reH1WJZBZeG38CRKAqJcTO9kzxaHVZ8bZz65WqtzgTxhG5cXrkyD9/r w69i0qZPAYhUFBri/at4x7GPOG7yK54Kw0FsZhXsmlmfVuhe0XEOxrJ7EATeA3zbeLLb UZlv86HPsJc4IAY8tqxRHHhqSFypS2M/JsIsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zSVzlWFMvPeuCU4XSjVpKAQdQZgJSd2Hp7k5EYAOpiw=; b=JhGX1yLcQadtZWAIw7BaLHsBYf3kyaLI0UG0Wn/O64UiW3jONwJbRqx5jWiAd1xQ3c NA/0As0/at23glOcT0F7o+us93yzo5zbh5FX0FxP+Zje9AbCOJh7Pe5YbsaywMx19Wsf BRKCwM3xnibTZAyGJOCCOc3AylymYWTB8zF4QPD9dME0XCYNufKfE6tUuRIvEojz9Iz6 Pa7Mt8i14v12CC7ts4MX5lUQw+7TjkUXOn5+IrPQqAPGQQlbmqFUhxvI4/tafb0MLGHn 9Rt2k5z6aJtFJvNoeleXKIOMoGRrgh/lGsBU5A3/naVAHgQ+Wwt5YlC/+Fu7C5QPKzJX X6Sw== X-Gm-Message-State: AOAM533HeqBRy1/Nnf2NCmr1y+/oNEVDaWNiCIstsjzqTXyUOJJwofgO rut5NMLHFMa/DX7hZ22PvRvYc9uMCs01PVMd12r49Jxf X-Google-Smtp-Source: ABdhPJx5nZ7o48styIQs7CWEZV9rTKukEjo3WOYKv2YnJyVQvYbTAqZA3QCctxquD5JmZZ7VFmhInMidVuhzYkP+aoY= X-Received: by 2002:a50:c181:: with SMTP id m1mr470292edf.27.1592271025647; Mon, 15 Jun 2020 18:30:25 -0700 (PDT) MIME-Version: 1.0 References: <87zh934xcc.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zh934xcc.fsf@hobgoblin.ariadne.com> From: Maxim Sobolev Date: Mon, 15 Jun 2020 18:30:14 -0700 Message-ID: To: "Dale R. Worley" Cc: russp=40microsoft.com@dmarc.ietf.org, sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000dec85705a8297c31" Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 01:30:46 -0000 --000000000000dec85705a8297c31 Content-Type: text/plain; charset="UTF-8" That actually a great idea Dale, I was thinking along the same lines yesterday but dismissed the idea as too extravagant. Nobody prevents multiparty body to carry on both "Rating" and media description! On the implementation side of things, handling multiparty in 183 would be way less expensive proposition, compared to adding new class of status codes. IMHO. -Max On Mon., Jun. 15, 2020, 6:24 p.m. Dale R. Worley, wrote: > Maxim Sobolev writes: > > [...] Simple header included into 18x provisional response should do > > the trick in 99% of practical cases. [...] > > One alternative would be to attach this information to 183 Session > Progress. 183 resembles 180, but it carries no semantics about > alerting: > > 21.1.5 183 Session Progress > > The 183 (Session Progress) response is used to convey information > about the progress of the call that is not otherwise classified. The > Reason-Phrase, header fields, or message body MAY be used to convey > more details about the call progress. > > Dale > --000000000000dec85705a8297c31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That actually a great idea Dale, I was thinking along the= same lines yesterday but dismissed the idea as too extravagant. Nobody pre= vents multiparty body to carry on both "Rating" and media descrip= tion! On the implementation side of things, handling multiparty in 183 woul= d be way less expensive proposition, compared to adding new class of status= codes. IMHO.

-Max
=
On Mon= ., Jun. 15, 2020, 6:24 p.m. Dale R. Worley, <worley@ariadne.com> wrote:
Maxim Sobolev <sobomax@sippysoft.com> writes:
> [...] Simple header included into 18x provisional response should do > the trick in 99% of practical cases. [...]

One alternative would be to attach this information to 183 Session
Progress.=C2=A0 183 resembles 180, but it carries no semantics about
alerting:

=C2=A0 =C2=A021.1.5 183 Session Progress

=C2=A0 =C2=A0The 183 (Session Progress) response is used to convey informat= ion
=C2=A0 =C2=A0about the progress of the call that is not otherwise classifie= d.=C2=A0 The
=C2=A0 =C2=A0Reason-Phrase, header fields, or message body MAY be used to c= onvey
=C2=A0 =C2=A0more details about the call progress.

Dale
--000000000000dec85705a8297c31-- From nobody Mon Jun 15 19:04:56 2020 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 F1F6E3A0F87 for ; Mon, 15 Jun 2020 19:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 HkxPJxRZsWCZ for ; Mon, 15 Jun 2020 19:04:49 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640133.outbound.protection.outlook.com [40.107.64.133]) (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 40A513A0F8B for ; Mon, 15 Jun 2020 19:04:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cKsZgUTBtHE1n+ZJ41KkhPAleM/Wt5R3YPSN4S2vp9cZesivnQrb7d7jnDK3mKVyvuM8BG1Bxr3LtYzFU9oHumqEd6rB6+M6qnuIIiPASbdl3ln9RKd+zfQnUrvK1knltF8lnDPjo8Td/DmsCZiG9P14gUNv762E6RHrkugup99xhYU9hsUOJYt6tNYLpidWJz14TqvBAi7H6V2QexGMm4LO9gpolkFXJ5ukvA6eIivBLPtmQY3EITf+220NWNSqVb/bTve2r77pW7XFLMNZfe0IfwlWsdpmndCLT5yLX72Cd3t3Q29QamjDIhzIxCgTWpcw/lst7VkuCA6n3sdSFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lg7xqdTt+bBFoqPn6AUn3nopGSbckmU2URXyGRyo1SE=; b=kV9YUaoPQE/Chs+mTzY62KN+Btji+F5Eb7LWSSGwTFKhGZSLl4RrfhULQdXYXKf++k5eDC/RjnAPzO/MEpRMFqubT7SgFvhr+wBV8+PnfjkdR5hYk+byLLY4ERo4FqiMqp8NOwBlxv5iZ8Z3gIzuk7H+ac2F6JLCIieGJMcJYHywNasQugRVJ7mW4ZFVFNjodl1Jkdu5NI5rkmE3yc+sTXI/LnmX0eJDyObc8AGtuhp+mrUgZmNgqi0C1wKQlCp0cH6gqgUSuYlUtBiI1XXrwsGYZjTcnF7HpcQRkuQE09om7kFv2HzqBGTknijyGiXSBWdl5Q7UlCJyKgXohSAEjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lg7xqdTt+bBFoqPn6AUn3nopGSbckmU2URXyGRyo1SE=; b=EQd/WWUvOlGMNEZU1W6+TRk/NOn+jdCTEEsD12L8aZYGG853J+iYEk3V0IEHsI09/odqtmxrZTuNwBnef4lVXuSrmokwquqWFrvJOlfrwp4ejAE5RpV85Emp/sHtwWEJyt6eVrlpe8iLAVezf2h81PtBrk1JJ/m23JI5q+cRkl0= Received: from MW2PR00MB0425.namprd00.prod.outlook.com (2603:10b6:302:b::13) by MW2PR00MB0410.namprd00.prod.outlook.com (2603:10b6:302:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3136.0; Tue, 16 Jun 2020 02:04:46 +0000 Received: from MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1]) by MW2PR00MB0425.namprd00.prod.outlook.com ([fe80::355d:adae:4fb3:d5f1%5]) with mapi id 15.20.3144.000; Tue, 16 Jun 2020 02:04:46 +0000 From: Russ Penar To: Maxim Sobolev , "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore Thread-Index: AQHWQ3zaH3aOGObzOUazu5TyCHrQM6jadGQAgAAIYBA= Date: Tue, 16 Jun 2020 02:04:46 +0000 Message-ID: References: <87zh934xcc.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=382fc7ec-6a5f-400e-9279-683f68f0e2f2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-16T02:00:13Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: sippysoft.com; dkim=none (message not signed) header.d=none;sippysoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8ab26a5f-bf2e-446a-74a4-08d81199a49c x-ms-traffictypediagnostic: MW2PR00MB0410: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZwDgKpZzObhtvtbjZKj+n2u/2gV2p6s1kjFeEEa03T3VIEncLI1YSsGiDFAieD3CSzdGop+3Pb+NOpbRrwtUsyVshBhv38rUhlfPAVQfKemI4F0QHNePkFr6HpMB+svyABV591RVFnV6Vaoyy4eOU4C6xujVTx/5oG7k30v/70P6YgGX5cG7QRBs/Q8eFPbyZHwXxFrj1hsf2dNMZUpdsC6eFgBj64No6/hNLQsy1qjwMYIJDgpbzoFia4OJ/pNcLo/N9Byh3gfgCuHX0s0UBSQcT+2k/rGvJI95dJkvgwZa0+H7rW6dmN0IQ3Vvok5snBfJKSMM42CMPvFDe7l37A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0425.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(64756008)(4326008)(66446008)(10290500003)(76116006)(6506007)(66556008)(9686003)(8676002)(2906002)(66946007)(478600001)(7696005)(33656002)(55016002)(82960400001)(82950400001)(53546011)(66476007)(186003)(52536014)(83380400001)(316002)(8936002)(86362001)(26005)(71200400001)(5660300002)(8990500004)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 9V7DgVg6eIfMVjBr8qSPngfJh26C4mFAyi0PsKNQx7xyfWJdd9fY/9kvnrD9n9B8jcxMbE/Nr32v8P1uqRFZx5eH8GsCc3VJY8nNhNmZxSJrRrKKqrC5DkpzPTBLNLPj4LfD/1PYhfCGKUaS36hb4Q+ZrvhL30MUwrwYNFZfYRGL5W5jA2KXDPRFy5vw2zbkpoWEiK6tdhOSpXrlmrANCOZycEl9jyAstWTX3mJsqE0tEAf1th1vNjYbqnGozSE55b28+U7fbePYy+/ma08XUNz4nhjDa+RxJ+Fm9zmKIAZwSNwEuu4Vbm2nOSvZMhsILS6uRINZfSAZ5AWBbN7siGysV76TYIsvnGAqJOzDzNl2jA9neoLfkQckYpc2v1md5WGVCe7zEAiKNTifwJGZYc+idhnZ8z8D525Gc7Pjz1GfaTvJOC44Eb2tTvDkNMn2UXjsfXJueH7jDukCymS/Oo0ukJwAdbROt26X57DExdA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR00MB04253A2CA1320CFE84CE203FB69D0MW2PR00MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0425.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ab26a5f-bf2e-446a-74a4-08d81199a49c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 02:04:46.1391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Vgj7ExNhDBZ6fQ74tcezSM2YHbM9CH7mZTznWsV1tUJ3IUM2+XMlPnKwGChl+j+jXLNGW5ntHYyDdF/k8L/sIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0410 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 02:04:51 -0000 --_000_MW2PR00MB04253A2CA1320CFE84CE203FB69D0MW2PR00MB0425namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW50ZXJlc3RpbmcsIHRoZSBuZXR3b3JrIHdpbGwga25vdyB0aGUgY2FsbC1yYXRpbmcgYW5kIGlz IGFibGUgdG8gZGVsaXZlciBpdCBwcmlvciB0byAxODAuICBJcyB0aW1pbmcgYSBwcm9ibGVtIGlu IHRoYXQgY2FzZT8NCi1ydXNzcA0KDQoNCkZyb206IE1heGltIFNvYm9sZXYgPHNvYm9tYXhAc2lw cHlzb2Z0LmNvbT4NClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAyMCA2OjMwIFBNDQpUbzogRGFs ZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlhZG5lLmNvbT4NCkNjOiBSdXNzIFBlbmFyIDxydXNzcEBt aWNyb3NvZnQuY29tPjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTog W3NpcGNvcmVdIHBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZHJhZnQtcGVuYXItaWV0Zi1z aXBjb3JlDQoNClRoYXQgYWN0dWFsbHkgYSBncmVhdCBpZGVhIERhbGUsIEkgd2FzIHRoaW5raW5n IGFsb25nIHRoZSBzYW1lIGxpbmVzIHllc3RlcmRheSBidXQgZGlzbWlzc2VkIHRoZSBpZGVhIGFz IHRvbyBleHRyYXZhZ2FudC4gTm9ib2R5IHByZXZlbnRzIG11bHRpcGFydHkgYm9keSB0byBjYXJy eSBvbiBib3RoICJSYXRpbmciIGFuZCBtZWRpYSBkZXNjcmlwdGlvbiEgT24gdGhlIGltcGxlbWVu dGF0aW9uIHNpZGUgb2YgdGhpbmdzLCBoYW5kbGluZyBtdWx0aXBhcnR5IGluIDE4MyB3b3VsZCBi ZSB3YXkgbGVzcyBleHBlbnNpdmUgcHJvcG9zaXRpb24sIGNvbXBhcmVkIHRvIGFkZGluZyBuZXcg Y2xhc3Mgb2Ygc3RhdHVzIGNvZGVzLiBJTUhPLg0KDQotTWF4DQoNCk9uIE1vbi4uLCBKdW4uIDE1 LCAyMDIwLCA2OjI0IHAubS4gRGFsZSBSLiBXb3JsZXksIDx3b3JsZXlAYXJpYWRuZS5jb208bWFp bHRvOndvcmxleUBhcmlhZG5lLmNvbT4+IHdyb3RlOg0KTWF4aW0gU29ib2xldiA8c29ib21heEBz aXBweXNvZnQuY29tPG1haWx0bzpzb2JvbWF4QHNpcHB5c29mdC5jb20+PiB3cml0ZXM6DQo+IFsu Li5dIFNpbXBsZSBoZWFkZXIgaW5jbHVkZWQgaW50byAxOHggcHJvdmlzaW9uYWwgcmVzcG9uc2Ug c2hvdWxkIGRvDQo+IHRoZSB0cmljayBpbiA5OSUgb2YgcHJhY3RpY2FsIGNhc2VzLiBbLi4uXQ0K DQpPbmUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gYXR0YWNoIHRoaXMgaW5mb3JtYXRpb24gdG8g MTgzIFNlc3Npb24NClByb2dyZXNzLiAgMTgzIHJlc2VtYmxlcyAxODAsIGJ1dCBpdCBjYXJyaWVz IG5vIHNlbWFudGljcyBhYm91dA0KYWxlcnRpbmc6DQoNCiAgIDIxLjEuNSAxODMgU2Vzc2lvbiBQ cm9ncmVzcw0KDQogICBUaGUgMTgzIChTZXNzaW9uIFByb2dyZXNzKSByZXNwb25zZSBpcyB1c2Vk IHRvIGNvbnZleSBpbmZvcm1hdGlvbg0KICAgYWJvdXQgdGhlIHByb2dyZXNzIG9mIHRoZSBjYWxs IHRoYXQgaXMgbm90IG90aGVyd2lzZSBjbGFzc2lmaWVkLiAgVGhlDQogICBSZWFzb24tUGhyYXNl LCBoZWFkZXIgZmllbGRzLCBvciBtZXNzYWdlIGJvZHkgTUFZIGJlIHVzZWQgdG8gY29udmV5DQog ICBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIGNhbGwgcHJvZ3Jlc3MuDQoNCkRhbGUNCg== --_000_MW2PR00MB04253A2CA1320CFE84CE203FB69D0MW2PR00MB0425namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkludGVyZXN0aW5nLCB0aGUgbmV0d29yayB3aWxsIGtub3cgdGhlIGNhbGwtcmF0aW5nIGFu ZCBpcyBhYmxlIHRvIGRlbGl2ZXIgaXQgcHJpb3IgdG8gMTgwLiZuYnNwOyBJcyB0aW1pbmcgYSBw cm9ibGVtIGluIHRoYXQgY2FzZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1ydXNzcDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBNYXhpbSBTb2JvbGV2ICZsdDtzb2JvbWF4QHNpcHB5c29mdC5jb20mZ3Q7IDxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEp1bmUgMTUsIDIwMjAgNjozMCBQTTxicj4NCjxiPlRvOjwvYj4gRGFs ZSBSLiBXb3JsZXkgJmx0O3dvcmxleUBhcmlhZG5lLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJ1 c3MgUGVuYXIgJmx0O3J1c3NwQG1pY3Jvc29mdC5jb20mZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtzaXBjb3JlXSBwbGVhc2UgcmV2aWV3 IGFuZCBjb21tZW50IG9uIGRyYWZ0LXBlbmFyLWlldGYtc2lwY29yZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGFjdHVhbGx5IGEgZ3JlYXQgaWRlYSBEYWxlLCBJ IHdhcyB0aGlua2luZyBhbG9uZyB0aGUgc2FtZSBsaW5lcyB5ZXN0ZXJkYXkgYnV0IGRpc21pc3Nl ZCB0aGUgaWRlYSBhcyB0b28gZXh0cmF2YWdhbnQuIE5vYm9keSBwcmV2ZW50cyBtdWx0aXBhcnR5 IGJvZHkgdG8gY2Fycnkgb24gYm90aCAmcXVvdDtSYXRpbmcmcXVvdDsgYW5kIG1lZGlhIGRlc2Ny aXB0aW9uISBPbiB0aGUgaW1wbGVtZW50YXRpb24gc2lkZSBvZiB0aGluZ3MsDQogaGFuZGxpbmcg bXVsdGlwYXJ0eSBpbiAxODMgd291bGQgYmUgd2F5IGxlc3MgZXhwZW5zaXZlIHByb3Bvc2l0aW9u LCBjb21wYXJlZCB0byBhZGRpbmcgbmV3IGNsYXNzIG9mIHN0YXR1cyBjb2Rlcy4gSU1ITy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1NYXg8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLi4sIEp1 bi4gMTUsIDIwMjAsIDY6MjQgcC5tLiBEYWxlIFIuIFdvcmxleSwgJmx0OzxhIGhyZWY9Im1haWx0 bzp3b3JsZXlAYXJpYWRuZS5jb20iPndvcmxleUBhcmlhZG5lLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWF4aW0gU29ib2xldiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNvYm9tYXhAc2lwcHlzb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnNvYm9tYXhAc2lwcHlzb2Z0LmNvbTwvYT4mZ3Q7IHdyaXRlczo8YnI+ DQomZ3Q7IFsuLi5dIFNpbXBsZSBoZWFkZXIgaW5jbHVkZWQgaW50byAxOHggcHJvdmlzaW9uYWwg cmVzcG9uc2Ugc2hvdWxkIGRvPGJyPg0KJmd0OyB0aGUgdHJpY2sgaW4gOTklIG9mIHByYWN0aWNh bCBjYXNlcy4gWy4uLl08YnI+DQo8YnI+DQpPbmUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gYXR0 YWNoIHRoaXMgaW5mb3JtYXRpb24gdG8gMTgzIFNlc3Npb248YnI+DQpQcm9ncmVzcy4mbmJzcDsg MTgzIHJlc2VtYmxlcyAxODAsIGJ1dCBpdCBjYXJyaWVzIG5vIHNlbWFudGljcyBhYm91dDxicj4N CmFsZXJ0aW5nOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsyMS4xLjUgMTgzIFNlc3Npb24gUHJv Z3Jlc3M8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIDE4MyAoU2Vzc2lvbiBQcm9ncmVzcykg cmVzcG9uc2UgaXMgdXNlZCB0byBjb252ZXkgaW5mb3JtYXRpb248YnI+DQombmJzcDsgJm5ic3A7 YWJvdXQgdGhlIHByb2dyZXNzIG9mIHRoZSBjYWxsIHRoYXQgaXMgbm90IG90aGVyd2lzZSBjbGFz c2lmaWVkLiZuYnNwOyBUaGU8YnI+DQombmJzcDsgJm5ic3A7UmVhc29uLVBocmFzZSwgaGVhZGVy IGZpZWxkcywgb3IgbWVzc2FnZSBib2R5IE1BWSBiZSB1c2VkIHRvIGNvbnZleTxicj4NCiZuYnNw OyAmbmJzcDttb3JlIGRldGFpbHMgYWJvdXQgdGhlIGNhbGwgcHJvZ3Jlc3MuPGJyPg0KPGJyPg0K RGFsZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MW2PR00MB04253A2CA1320CFE84CE203FB69D0MW2PR00MB0425namp_-- From nobody Tue Jun 16 16:29:13 2020 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 D6C243A0A6E for ; Tue, 16 Jun 2020 16:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_PHARMACY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 xWSVojgj2bB8 for ; Tue, 16 Jun 2020 16:29:10 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650105.outbound.protection.outlook.com [40.107.65.105]) (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 D0B103A0A6C for ; Tue, 16 Jun 2020 16:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y78+ht7ngXLRSUc5JQx+OnZo4hNFrQZF2ghJD8HXmvU8ZBf/p6vmw6iaqwK9B7f9uQ9Mh2UfjVr3AaMWj/9NDCaEln51FHW9pI41NdoxFFgjZ88iqIMc5HcIS5UL+x4NBbps9nfudPIVIVI5z4rHSEetSSnD6f7+sxly/7jqidTchhvVWhABRzBgeSCeCAByr3Wi47nSj3YVL6UQ5iMSepXxuaOO3UJTsEsxL4PgtdUNm3obNDb06B0Qb5ZkLTZiPxfAG9e1Gqp6QOI2HNeP+T51ED2BkM0APdhGikC7giZLiSfTzDRL3FbJ531JFusOuDXOv29H83gQM/y219f/5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xmfz4N8DZcMfl1CmjKK2N7xPuskXsEgwK+r1Yx18hZU=; b=ax0OusjTsTlnWZfnwyehhuDRpjXknhJgzg3a3KDQSE7XNgxy4lZtXLAKloVAQq1bU1QdmIz8eSRGqh+rgXlJHafj/aWf0faVdJjujid8M9IiqLDbGdNl79fIOR/ti0VMgC4HcYuo8GOE9VjbEtrEJLfqYCbmRUtTVD+G5clWi4IhJPd8sTFmonqf5/C4WJKLX5LmSewR/OqCMrZHNyaQzJaB6f07E5RhlAaURZNewizKwrkiLXVkzuFAyXwmiE6rRSnaXWOjgiSCaJl/tYUactTG6MJiz2QIGWfvCSNRFJBxRjck1OU40JRFDhosVSaA5ScSqSATFWzrsCTEyv1t+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xmfz4N8DZcMfl1CmjKK2N7xPuskXsEgwK+r1Yx18hZU=; b=b4NIZU7jXIoLvu0x5TZY12ogOEwQfr5/Ju5cDkb2Ss5saZNJFnGWtsJCTCT8tIHaIa56uRgzB3k5oxJ4Tw+hc8IIseT93Upz2MxgFZHNBihL4yoSogYnI9XJQWBGlpo0umSnDM7U30KJwzSB5C7kYl/WBZKF8G0TQ+JaCQngOm8= Received: from SN6PR00MB0432.namprd00.prod.outlook.com (2603:10b6:805:d::15) by SN6PR00MB0382.namprd00.prod.outlook.com (2603:10b6:805:c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3141.0; Tue, 16 Jun 2020 23:29:05 +0000 Received: from SN6PR00MB0432.namprd00.prod.outlook.com ([fe80::4904:d78c:392c:3dd7]) by SN6PR00MB0432.namprd00.prod.outlook.com ([fe80::4904:d78c:392c:3dd7%6]) with mapi id 15.20.3145.000; Tue, 16 Jun 2020 23:29:05 +0000 From: Russ Penar To: Cary FitzGerald , Russ Penar CC: "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AdZBFbmIYErjvgZESFeR9rthnkycuwBbjCWAAGuLcFA= Date: Tue, 16 Jun 2020 23:29:05 +0000 Message-ID: References: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> In-Reply-To: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=05aa7563-370b-4b87-a3f3-fbb1794c949a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-16T23:01:39Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: employees.org; dkim=none (message not signed) header.d=none;employees.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d1157032-6bb0-4854-83c6-08d8124d0fb2 x-ms-traffictypediagnostic: SN6PR00MB0382: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lc3nT9QLrzAYcxLwWCct6lljki0TMCskOL5v4cUaENASm+DagiV9iwa8fHGjZ1YCy/q2AWhu4Qr6TNbNCzJrS2ERwmpHecf2COTVfLg8DoTQXt4s3uUhn7BE81fmvwzVRcD8LC3FguYtmBvQVJU9RQQNvsZpMEZ/aattBrpavkrvh8cX063k14zlTNDGWSxnUAogDp+GpFMmGMDQw3bZ0NaGilvLQi2zAuBM1V/Ht8YXz5hBBFI7MHS6hleWUpvHn5kabCffGInoC2JNQYZAojfQYirq7Uh/RD2RARXeKcXsOXwUnCJhenvSmuMzkjPwLifEowhF6L6O+42f0vAwfKXJVzQJ211o1Os3U1xoVMvI7tH3pY3ZR8T2iUKzAGuKd43eHeStwm97mMok1BXaVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR00MB0432.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(8676002)(82950400001)(10290500003)(82960400001)(7696005)(33656002)(8990500004)(186003)(4326008)(26005)(2906002)(77540400001)(71200400001)(5660300002)(8936002)(6506007)(66946007)(66476007)(64756008)(66446008)(66556008)(76116006)(110136005)(9686003)(53546011)(55016002)(498600001)(966005)(52536014)(86362001)(166002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: N3/4KO0XQ6UmoI7kSEMTT21PAyF/3lU6H4lXaq7LKVRqeweqsGEe7urOBQqYt2li2l+2s+7bQ5QxrtVsJMUfw+cyEB18pTALLRa7cZ579t1ucHAZGA8DjrG/oPh76ZFQNO2nCuxFbe9ygTJq2E+OA4ajGBxiMPF4bfzg640XUB+D8m4k3hZipB8SDqHTDCcoeJtLT4Ux5xk/ksXdfrY3gomo+ir+m7UT3Qq7jGPoAbUNbEDnDqzyGrT400ZC7dlgUdZaRyjSH6s88DActO8y2iXvC0DGlD9EiQpgOFtLizxfSYAU8d+GXxzMCc9TusedekC8YU0E4hhlm/lDUzz+ZIqkhvjrbDNufrZ0wxRm0g4GXL68u6d2qs8xIzMiqsNp+WaH7VIuMD5KnggR/sX2Wwm3c8i2k3OOihDbbppD/vBBgsY9gNvlVOsKkix1Qp/S4WuHwcGFx23s/bwPWQ55tAYMlXWfnUMuq558ngib1k8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR00MB04323CCC61681345FC443636B69D0SN6PR00MB0432namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR00MB0432.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1157032-6bb0-4854-83c6-08d8124d0fb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 23:29:05.6954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OfgD0efG3NLLYgFM9dcrT49zPA4QPVyDfrwsvxYXf0BX7ZQWswV893lAnnwSJpt5Tf5h+g0tJ6sizVVWT5u4Ug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0382 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 23:29:12 -0000 --_000_SN6PR00MB04323CCC61681345FC443636B69D0SN6PR00MB0432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciBzaGFyaW5nIHRoZSBwZXJzcGVjdGl2ZSBDYXJ5LA0KDQpJIHRoaW5rIHRo ZSBhZGRpdGlvbmFsIG9ic2VydmFiaWxpdHkgYW5kIGF3YXJlbmVzcyBvZiByZW1lZGlhdGlvbiDi gJhmcm9udCBkb29y4oCZIGlzIHdvcnRoIHRoZSByaXNrIG9mIHNwYW1tZXJzIHVzaW5nIHRoZSBt ZWNoYW5pc20gdG8gdHVuZSB0aGVpciBhdHRhY2tzLg0KDQpJIGVudmlzaW9uIHRoZSBtZWNoYW5p c20gYmVpbmcgdXNlZCBieSBvcmlnaW5hdGluZyBzZXJ2aWNlIHByb3ZpZGVycyBhcyBzaWduYWwg Zm9yIHByb2JsZW1hdGljIGNhbGxpbmcgY29ycmlkb3JzIG9yIG5ld2x5IHBvcnRlZCBudW1iZXJz IG9yIHZhbHVlLWFkZCDigJhwcm90ZWN0aW9u4oCZIHNlcnZpY2UgZm9yIGxhcmdlIGNhbGwgY2Vu dGVyIGN1c3RvbWVycywgYXMgYSBmZXcgZXhhbXBsZXMuDQoNClRoZSBlbmQgcmVzdWx0IHNob3Vs ZCBiZSBpbXByb3ZlZCBhbmFseXRpY3MsIGltcHJvdmVkIHRocm91Z2hwdXQgb2Ygd2FudGVkIGNh bGxzLCBhbmQgYmV0dGVyIHVzZXIgZXhwZXJpZW5jZS4NCg0KV2hlbiBGQ0MgYXNrZWQgZm9yIHB1 YmxpYyBjb21tZW50IG9uIG1pc2xhYmVsZWQgY2FsbHMsIG11bHRpcGxlIHZvaWNlIHByb3ZpZGVy cyBhbmQgaW5kdXN0cnkgYXNzb2NpYXRpb25zIGNvbXBsYWluZWQgc2F5aW5nIHRoZSBpc3N1ZSBu ZWVkcyBhZGRyZXNzZWQuICBPbmUgc29sdXRpb24gbWF5IGJlIHRvIGltcG9zZSBsaWFiaWxpdHkg b24gdGVybWluYXRpbmcgY2FycmllciBmb3IgcGVyZm9ybWFuY2UvYWNjdXJhY3kgb2YgYW5hbHl0 aWNzIHVzZWQgd2hlbiBkZWxpdmVyaW5nIGNhbGxzLiAgUGVyaGFwcyB0aGUgcHJvcG9zZWQgcGVy LWNhbGwgbWVjaGFuaXNtIHdvdWxkIGFsbG93IEZDQyB0byBhdm9pZCBzdWNoIGFuIGFwcHJvYWNo Pw0KDQpCZXN0IHJlZ2FyZHMsDQpSdXNzDQoNCg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2FyeSBGaXR6R2VyYWxkDQpTZW50OiBTdW5kYXks IEp1bmUgMTQsIDIwMjAgMTI6NDIgUE0NClRvOiBSdXNzIFBlbmFyIDxydXNzcD00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW0VY VEVSTkFMXSBSZTogW3NpcGNvcmVdIHBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZHJhZnQt cGVuYXItc2lwY29yZS1yYXRpbmdwcm92aWRlZC0wMA0KDQpJ4oCZbSBub3QgYSBmYW4gb2YgdGhl IHVzZSBjYXNlLiAgU2hhcmluZyBkZXRhaWxzIGFib3V0IHBlci1jYWxsIHNwYW0gcmF0aW5ncyB3 aXRoIHBvdGVudGlhbCBzcGFtbWVycyBzZWVtcyB1bndpc2UuDQoNCkluIHRoZSByZWFsIHdvcmxk LCBjYWxscyBtYXJrZWQg4oCcc3BhbSBsaWtlbHnigJ0gdGhhdCBjb21lIHRvIG15IHBob25lIGFy ZSBhbnN3ZXJlZCBieSB2b2ljZSBtYWlsLiAgTW9zdCBzcGFtbWVycyB3b27igJl0IGV2ZW4gYm90 aGVyIHdpdGggdGhlIGFpcnRpbWUgdG8gbGVhdmUgYSBtZXNzYWdlLiAgVGhlIHBoYXJtYWN5IGZy b20gdGhlIGludHJvZHVjdGlvbiB3b3VsZCBkbyB0aGF0LCBwcmVzdW1hYmx5LiAgSXTigJlzIHVu bGlrZWx5IHRoZXnigJlkIGRvIG1vcmUgaW4gb3JkZXIgdG8gcmVhY2ggYSBzaW5nbGUgY2FsbGVl LiAgRml4aW5nIGxhcmdlIHNjYWxlIHByb2JsZW1zIChpbnRlci1TUCkgaXMgbGFyZ2VyIHByb2Js ZW0uDQoNClRoaXMgbWVjaGFuaXNtIGlzIHZhbHVlLW5ldXRyYWw6ICBsZWdpdGltYXRlIGNhbGxl cnMgYXJlIG5vdCBkaXN0aW5ndWlzaGFibGUgZnJvbSBiYWQgYWN0b3JzLiAgQmFkIGFjdG9ycyAq bWlnaHQqIGFiYW5kb24gdGhlIGZpZWxkIGlmIHRoZXkgc2VlIHRoZXkgYXJlIG1hcmtlZCBhcyBz cGFtLCBvciB0aGV5IG1pZ2h0IHRyeSB0byBhZGp1c3QgdGhlaXIgYXR0YWNrIHRvIGxvd2VyIHRo ZWlyIHNjb3Jlcy4gIEkgY2Fu4oCZdCB0aGluayBvZiBhIHNpbWlsYXIgbWVjaGFuaXNtIGZvciBl bWFpbCBiZXlvbmQgbWFuYWdpbmcgb25l4oCZcyByZXB1dGF0aW9uLg0KDQpGaXhpbmcgdGhlIGFu YWx5dGljcyBTUOKAmXMgbG9naWMgZm9yIGxlZ2l0aW1hdGUgY2FsbGVyIHdvdWxkIGNlcnRhaW5s eSBpbmNsdWRlIHRoZSBjYWxsZXIncyBhc3NlcnRpb24gb2YgaWRlbnRpdHkuICBJIHNlZSBhIGNv bmNlcHR1YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIFNUSVIgYW5kIHRoaXMgYXBwcm9hY2gsIGJ1dCBJ 4oCZbSBub3Qgc3VyZSBJIHNlZSBhIHNpZ25pZmljYW50IGFkdmFudGFnZSB0byBtYWtpbmcgdGhl IGFzc2VydGlvbiBhZnRlciB0aGUgZmFjdC4NCg0KVGhlIG1vc3Qgb2J2aW91cyBtZXRyaWMgZm9y IGFuICJhbmFseXRpY3Mgc2VydmljZSBwcm92aWRlcuKAnSBpcyByZXB1dGF0aW9uIGFuZCBpZGVu dGl0eSBpcyB0aGUga2V5LiAgQXNraW5nIG91dCBvZiBpZ25vcmFuY2UsIGFyZSB0aGVyZSBtYXJr ZXQtZHJpdmVuIHJlcXVpcmVtZW50cyBjYWxsaW5nIGZvciBzb21ldGhpbmcgbW9yZT8NCg0KQ2Fy eS4NCg0KDQpPbiBKdW4gMTIsIDIwMjAsIGF0IDU6MDEgUE0sIFJ1c3MgUGVuYXIgPHJ1c3NwPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cnVzc3A9NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkJhc2VkIG9uIGVhcmx5IGZlZWRiYWNrLCBJIHVw ZGF0ZWQgdGhlIG5hbWUgYW5kIHByb3Bvc2VkIGNvZGUgbnVtYmVyLg0KUGxlYXNlIHJldmlldyB0 aGUgbmV3bHkgbmFtZWQgZHJhZnQsIEkgd2VsY29tZSBldmVyeW9uZeKAmXMgcGVyc3BlY3RpdmUs IHRoYW5rIHlvdSENCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVu YXItc2lwY29yZS1yYXRpbmdwcm92aWRlZC88aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZkcmFmdC1wZW5hci1zaXBjb3JlLXJhdGluZ3Byb3ZpZGVkJTJGJmRhdGE9MDIlN0Mw MSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3Q2JmZjE1NjQ4MmQzOTRlMGFmYWZhMDhkODEwOWIw YzNjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdDMCU3QzYzNzI3NzYw NTQwMTY5NjY5NyZzZGF0YT0zak9RQ2RRYW5idjRFYndoOWx0SzFrSnB0OFh4Q3d5dTFQR2MlMkJM TzlUaXclM0QmcmVzZXJ2ZWQ9MD4NCg0KRnJvbTogUnVzcyBQZW5hcg0KU2VudDogRnJpZGF5LCBK dW5lIDEyLCAyMDIwIDI6NTUgUE0NClRvOiAnc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29y ZUBpZXRmLm9yZz4nIDxzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPj4N ClN1YmplY3Q6IHBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZHJhZnQtcGVuYXItaWV0Zi1z aXBjb3JlDQoNCkhpIEFsbCwNClBsZWFzZSB0YWtlIGEgbG9vayBhdCBteSBwcm9wb3NlZCBkcmFm dCByZWdhcmRpbmcgYSAxeHggbWVzc2FnZSBsZXR0aW5nIGNhbGxlciBrbm93IHRoZWlyIGNhbGwg aXMgcmF0ZWQgcG9vcmx5L2FtYmlndW91c2x5Lg0KT25lIGVhcmx5IGZlZWRiYWNrIGlzIDE4NCBt YXkgYmUgdG9vIGNsb3NlIHRvIHByb2dyZXNzIG1lc3NhZ2VzIGFzc29jaWF0ZWQgd2l0aCByaW5n YmFjaywgYW5kIEnigJlkIGxvdmUgdG8gZ2V0IG1vcmUgcGVyc3BlY3RpdmVzLg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVuYXItaWV0Zi1zaXBjb3JlLzxodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LXBlbmFyLWlldGYtc2lwY29yZSUy RiZkYXRhPTAyJTdDMDElN0NydXNzcCU0MG1pY3Jvc29mdC5jb20lN0NiZmYxNTY0ODJkMzk0ZTBh ZmFmYTA4ZDgxMDliMGMzYyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMCU3 QzAlN0M2MzcyNzc2MDU0MDE2OTY2OTcmc2RhdGE9RUZDNjZMWHR1bFAyVjFJbE1iYyUyQmVIaGdE ZllnbmRabFdseXBpWVd5cHVjJTNEJnJlc2VydmVkPTA+DQpCZXN0IHJlZ2FyZHMsDQpSdXNzDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBt YWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lwY29yZSZkYXRhPTAyJTdDMDElN0Ny dXNzcCU0MG1pY3Jvc29mdC5jb20lN0NiZmYxNTY0ODJkMzk0ZTBhZmFmYTA4ZDgxMDliMGMzYyU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMCU3QzAlN0M2MzcyNzc2MDU0MDE2 OTY2OTcmc2RhdGE9blh3UzRFdVJSalM5cmdrSnV3RXdSalZ1am1vcWNWcFpsdjNIY0JnaDFWUSUz RCZyZXNlcnZlZD0wPg0KDQo= --_000_SN6PR00MB04323CCC61681345FC443636B69D0SN6PR00MB0432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgcGVyc3BlY3RpdmUgQ2Fy eSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgYWRkaXRpb25hbCBvYnNlcnZh YmlsaXR5IGFuZCBhd2FyZW5lc3Mgb2YgcmVtZWRpYXRpb24g4oCYZnJvbnQgZG9vcuKAmSBpcyB3 b3J0aCB0aGUgcmlzayBvZiBzcGFtbWVycyB1c2luZyB0aGUgbWVjaGFuaXNtIHRvIHR1bmUgdGhl aXIgYXR0YWNrcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZW52aXNpb24gdGhl IG1lY2hhbmlzbSBiZWluZyB1c2VkIGJ5IG9yaWdpbmF0aW5nIHNlcnZpY2UgcHJvdmlkZXJzIGFz IHNpZ25hbCBmb3IgcHJvYmxlbWF0aWMgY2FsbGluZyBjb3JyaWRvcnMgb3IgbmV3bHkgcG9ydGVk IG51bWJlcnMgb3IgdmFsdWUtYWRkIOKAmHByb3RlY3Rpb27igJkgc2VydmljZSBmb3IgbGFyZ2Ug Y2FsbCBjZW50ZXIgY3VzdG9tZXJzLCBhcyBhIGZldyBleGFtcGxlcy4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZW5kIHJlc3VsdCBzaG91bGQgYmUgaW1wcm92ZWQgYW5hbHl0aWNzLCBp bXByb3ZlZCB0aHJvdWdocHV0IG9mIHdhbnRlZCBjYWxscywgYW5kIGJldHRlciB1c2VyIGV4cGVy aWVuY2UuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBGQ0MgYXNrZWQgZm9yIHB1Ymxp YyBjb21tZW50IG9uIG1pc2xhYmVsZWQgY2FsbHMsIG11bHRpcGxlIHZvaWNlIHByb3ZpZGVycyBh bmQgaW5kdXN0cnkgYXNzb2NpYXRpb25zIGNvbXBsYWluZWQgc2F5aW5nIHRoZSBpc3N1ZSBuZWVk cyBhZGRyZXNzZWQuJm5ic3A7IE9uZSBzb2x1dGlvbiBtYXkgYmUgdG8gaW1wb3NlIGxpYWJpbGl0 eSBvbiB0ZXJtaW5hdGluZyBjYXJyaWVyIGZvciBwZXJmb3JtYW5jZS9hY2N1cmFjeQ0KIG9mIGFu YWx5dGljcyB1c2VkIHdoZW4gZGVsaXZlcmluZyBjYWxscy4mbmJzcDsgUGVyaGFwcyB0aGUgcHJv cG9zZWQgcGVyLWNhbGwgbWVjaGFuaXNtIHdvdWxkIGFsbG93IEZDQyB0byBhdm9pZCBzdWNoIGFu IGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SdXNzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBzaXBjb3JlICZsdDtzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPkNhcnkgRml0ekdlcmFsZDxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bmUgMTQsIDIwMjAgMTI6NDIgUE08YnI+DQo8Yj5U bzo8L2I+IFJ1c3MgUGVuYXIgJmx0O3J1c3NwPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gW0VYVEVSTkFMXSBSZTogW3NpcGNvcmVdIHBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24g ZHJhZnQtcGVuYXItc2lwY29yZS1yYXRpbmdwcm92aWRlZC0wMDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IGEgZmFuIG9mIHRoZSB1c2UgY2FzZS4gJm5i c3A7U2hhcmluZyBkZXRhaWxzIGFib3V0IHBlci1jYWxsIHNwYW0gcmF0aW5ncyB3aXRoIHBvdGVu dGlhbCBzcGFtbWVycyBzZWVtcyB1bndpc2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgcmVhbCB3b3JsZCwgY2FsbHMgbWFya2VkIOKAnHNwYW0g bGlrZWx54oCdIHRoYXQgY29tZSB0byBteSBwaG9uZSBhcmUgYW5zd2VyZWQgYnkgdm9pY2UgbWFp bC4gJm5ic3A7TW9zdCBzcGFtbWVycyB3b27igJl0IGV2ZW4gYm90aGVyIHdpdGggdGhlIGFpcnRp bWUgdG8gbGVhdmUgYSBtZXNzYWdlLiAmbmJzcDtUaGUgcGhhcm1hY3kgZnJvbSB0aGUgaW50cm9k dWN0aW9uIHdvdWxkIGRvIHRoYXQsIHByZXN1bWFibHkuICZuYnNwO0l04oCZcyB1bmxpa2VseQ0K IHRoZXnigJlkIGRvIG1vcmUgaW4gb3JkZXIgdG8gcmVhY2ggYSBzaW5nbGUgY2FsbGVlLiAmbmJz cDtGaXhpbmcgbGFyZ2Ugc2NhbGUgcHJvYmxlbXMgKGludGVyLVNQKSBpcyBsYXJnZXIgcHJvYmxl bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBtZWNoYW5pc20gaXMgdmFsdWUtbmV1dHJhbDogJm5ic3A7bGVnaXRpbWF0ZSBjYWxsZXJz IGFyZSBub3QgZGlzdGluZ3Vpc2hhYmxlIGZyb20gYmFkIGFjdG9ycy4gJm5ic3A7QmFkIGFjdG9y cyAqbWlnaHQqIGFiYW5kb24gdGhlIGZpZWxkIGlmIHRoZXkgc2VlIHRoZXkgYXJlIG1hcmtlZCBh cyBzcGFtLCBvciB0aGV5IG1pZ2h0IHRyeSB0byBhZGp1c3QgdGhlaXIgYXR0YWNrIHRvIGxvd2Vy IHRoZWlyIHNjb3Jlcy4gJm5ic3A7SQ0KIGNhbuKAmXQgdGhpbmsgb2YgYSBzaW1pbGFyIG1lY2hh bmlzbSBmb3IgZW1haWwgYmV5b25kIG1hbmFnaW5nIG9uZeKAmXMgcmVwdXRhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rml4aW5nIHRo ZSBhbmFseXRpY3MgU1DigJlzIGxvZ2ljIGZvciBsZWdpdGltYXRlIGNhbGxlciB3b3VsZCBjZXJ0 YWlubHkgaW5jbHVkZSB0aGUgY2FsbGVyJ3MgYXNzZXJ0aW9uIG9mIGlkZW50aXR5LiAmbmJzcDtJ IHNlZSBhIGNvbmNlcHR1YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIFNUSVIgYW5kIHRoaXMgYXBwcm9h Y2gsIGJ1dCBJ4oCZbSBub3Qgc3VyZSBJIHNlZSBhIHNpZ25pZmljYW50IGFkdmFudGFnZSB0byBt YWtpbmcgdGhlDQogYXNzZXJ0aW9uIGFmdGVyIHRoZSBmYWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbW9zdCBvYnZpb3VzIG1ldHJp YyBmb3IgYW4gJnF1b3Q7YW5hbHl0aWNzIHNlcnZpY2UgcHJvdmlkZXLigJ0gaXMgcmVwdXRhdGlv biBhbmQgaWRlbnRpdHkgaXMgdGhlIGtleS4gJm5ic3A7QXNraW5nIG91dCBvZiBpZ25vcmFuY2Us IGFyZSB0aGVyZSBtYXJrZXQtZHJpdmVuIHJlcXVpcmVtZW50cyBjYWxsaW5nIGZvciBzb21ldGhp bmcgbW9yZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNhcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdW4gMTIsIDIwMjAsIGF0IDU6MDEgUE0sIFJ1c3Mg UGVuYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpydXNzcD00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0 Zi5vcmciPnJ1c3NwPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24g ZWFybHkgZmVlZGJhY2ssIEkgdXBkYXRlZCB0aGUgbmFtZSBhbmQgcHJvcG9zZWQgY29kZSBudW1i ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q bGVhc2UgcmV2aWV3IHRoZSBuZXdseSBuYW1lZCBkcmFmdCwgSSB3ZWxjb21lIGV2ZXJ5b25l4oCZ cyBwZXJzcGVjdGl2ZSwgdGhhbmsgeW91ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRm Lm9yZyUyRmRvYyUyRmRyYWZ0LXBlbmFyLXNpcGNvcmUtcmF0aW5ncHJvdmlkZWQlMkYmYW1wO2Rh dGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3Q2JmZjE1NjQ4MmQzOTRlMGFmYWZh MDhkODEwOWIwYzNjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdDMCU3 QzYzNzI3NzYwNTQwMTY5NjY5NyZhbXA7c2RhdGE9M2pPUUNkUWFuYnY0RWJ3aDlsdEsxa0pwdDhY eEN3eXUxUEdjJTJCTE85VGl3JTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iY29sb3I6 IzA1NjNDMSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVuYXItc2lw Y29yZS1yYXRpbmdwcm92aWRlZC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlJ1c3MgUGVuYXI8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgSnVuZSAxMiwgMjAyMCAyOjU1IFBNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4nPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDU2M0MxIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT4nICZsdDs8YSBocmVmPSJtYWlsdG86 c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPnNpcGNvcmVAaWV0 Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cGxlYXNlIHJldmlldyBhbmQgY29tbWVu dCBvbiBkcmFmdC1wZW5hci1pZXRmLXNpcGNvcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbCw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB0YWtl IGEgbG9vayBhdCBteSBwcm9wb3NlZCBkcmFmdCByZWdhcmRpbmcgYSAxeHggbWVzc2FnZSBsZXR0 aW5nIGNhbGxlciBrbm93IHRoZWlyIGNhbGwgaXMgcmF0ZWQgcG9vcmx5L2FtYmlndW91c2x5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGVh cmx5IGZlZWRiYWNrIGlzIDE4NCBtYXkgYmUgdG9vIGNsb3NlIHRvIHByb2dyZXNzIG1lc3NhZ2Vz IGFzc29jaWF0ZWQgd2l0aCByaW5nYmFjaywgYW5kIEnigJlkIGxvdmUgdG8gZ2V0IG1vcmUgcGVy c3BlY3RpdmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFm dC1wZW5hci1pZXRmLXNpcGNvcmUlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9z b2Z0LmNvbSU3Q2JmZjE1NjQ4MmQzOTRlMGFmYWZhMDhkODEwOWIwYzNjJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdDMCU3QzYzNzI3NzYwNTQwMTY5NjY5NyZhbXA7c2Rh dGE9RUZDNjZMWHR1bFAyVjFJbE1iYyUyQmVIaGdEZllnbmRabFdseXBpWVd5cHVjJTNEJmFtcDty ZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVuYXItaWV0Zi1zaXBjb3JlLzwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S dXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA1NjNDMSI+c2lwY29yZUBp ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpcGNvcmUmYW1w O2RhdGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3Q2JmZjE1NjQ4MmQzOTRlMGFm YWZhMDhkODEwOWIwYzNjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdD MCU3QzYzNzI3NzYwNTQwMTY5NjY5NyZhbXA7c2RhdGE9blh3UzRFdVJSalM5cmdrSnV3RXdSalZ1 am1vcWNWcFpsdjNIY0JnaDFWUSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDU2M0MxIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR00MB04323CCC61681345FC443636B69D0SN6PR00MB0432namp_-- From nobody Tue Jun 16 16:51:33 2020 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 1649C3A0AD3 for ; Tue, 16 Jun 2020 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 OZn-YJV1AENg for ; Tue, 16 Jun 2020 16:51:30 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640113.outbound.protection.outlook.com [40.107.64.113]) (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 8977B3A0AD5 for ; Tue, 16 Jun 2020 16:51:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dMjlUXD6mdMqOIbE8dk7YknLnqnW5rGMBgy2SjkI4YFYJl92iAxpErEd45FRsYd5zdjglCP8cWrr46ekoc6qqXAJJyPV79wNgpX5jMAHImiIuGrueQz2fZ2ZasOkNEsCABYrLkihuCypuc9qRUE4bt+G8XMNftjcMngnJq3f2qnd667QKmHeR60ax+862s/dnmqGoRDSdaqOYE5WXT+h039ylSWgKD5ad3F5qOnaE6FXAbsiQZp4orfqbCQFBtpE8TaC/ANQVtcfemyk+VOs9t71+DDuR8dIHokbmwwxilz1bGyCJUPI7IbH2xOPWW3jwYy7kq7/S42qRqJRz6Ya6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UUU3bp/BS/6CfC2wBn+KwwNkBrU5DxUB9NrX0cWMYw=; b=aAjB7Hak7dGcbk9VvkbEVryJbAjoPbKek4cYmVqkisxNyC5K34Darhhei8fioDprpG3SJqz6Pi9PtBoEgF+8DLSiFtVrZswl7RRf/x8N7yH+fmwg4jaSdmTyUKaCUWsA3dd70NP9r0Pj9WjE6GyBd5fhYG7wPtS4TjOorRRahGHqdBojMIbzhT9tylpE47pEc31XLRdHWDV2s89ogLixZEKYjN8iQXieeNY5n7AStIdGk5Qs7zpo1yj9Su+pQZJLpZv28AuzbLPEESUweI00+b05VjNrXeq3Mx1Bpmg56olEvu/aHxL8/ivUh5Fph//GRKbSddUTc7yA6GBQTeO9jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UUU3bp/BS/6CfC2wBn+KwwNkBrU5DxUB9NrX0cWMYw=; b=GcAkxd8khyO6nVo7vpyL3vtWgnp4Yv/yQDY8RxXnjHBkSKJCRp8nzp1XPnRTsrfEOL/LZLrJXywf9GzE7rYvmmvwgCZCUeBjLHCu4gwSQOtUzhKX7B5gO/nnqWBYfOYEetFSkUn2m0Jw6ohwtym+4qagUt9CmXunKnGrl58n0xE= Received: from SN6PR00MB0432.namprd00.prod.outlook.com (2603:10b6:805:d::15) by SN6PR00MB0383.namprd00.prod.outlook.com (2603:10b6:805:c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3146.0; Tue, 16 Jun 2020 23:51:29 +0000 Received: from SN6PR00MB0432.namprd00.prod.outlook.com ([fe80::4904:d78c:392c:3dd7]) by SN6PR00MB0432.namprd00.prod.outlook.com ([fe80::4904:d78c:392c:3dd7%6]) with mapi id 15.20.3145.000; Tue, 16 Jun 2020 23:51:29 +0000 From: Russ Penar To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AQHWQquEDCucL7H+DkKDs6dtNJPj2Kjb5xFA Date: Tue, 16 Jun 2020 23:51:28 +0000 Message-ID: References: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> (caryfitz@employees.org) <87blll5g5f.fsf@hobgoblin.ariadne.com> In-Reply-To: <87blll5g5f.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=66391426-43c0-493c-9ca0-6e147205c961; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-16T23:31:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: db669dd2-6979-4c46-c812-08d81250304e x-ms-traffictypediagnostic: SN6PR00MB0383: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wYePZ3kiB2yOFQHjVts9sxc77DpigAOZJVddKAg3OMyB++0ogjMgNrRmiSkYbHa2VSCRDCJtN6+QNlZev0RNQ22mDs11mIatpEnwrDcRnfaVv6eutSokYJER3ZiUpU6khPROq3x6sQjya3tkmJznsQz2xVsu7IxVUzG7WOVOSXBZUiog6Ts0564Robw+sPLvKhN9TgJmLpVu0br7dPGc9zv8NzLEGdXnf4OjU9BmEaEdTNbfLES5FfM3Qo8JuSfxKQ59oCBL2lgyz+obGRk8hyg8dQpiRFOXiXl8iol6ImDULemmGxZg0mZ8e2UT+xerlmwAwCQs1jaoyxrPnvsTQ0JvDJzEI/XTkeBzHK/cl8xzaqavBoXdsXxgeQwgXD5NGFI8CZrJZY9iXf7gmysinA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR00MB0432.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(39860400002)(346002)(136003)(76116006)(66946007)(66476007)(66446008)(66556008)(64756008)(86362001)(5660300002)(10290500003)(52536014)(77540400001)(8990500004)(33656002)(55016002)(478600001)(9686003)(82950400001)(82960400001)(966005)(2906002)(26005)(316002)(186003)(8936002)(53546011)(110136005)(6506007)(83380400001)(71200400001)(7696005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: BVV4C1W4HGSvIXMB+SRMYOK95n6UIweaL8NEMzJryWSb+RgsyZ0g6/5tWmJHDstmDQuBzZoJd4pqXFj7hyarXuBNPSfepHf8/Cyf3HygCMYgLZagyWJF54bLIbTLWpQqOP1lXF/rb3MPVqy+Xy6bP3WChIA4ecTtQCMkA4qz9RniNf8YCaJH091l4hb+upHjCnqkD/OuXCuXkNKGRarpXB2ythkC6JV+AM0c5GnopoB5AdPt+L/zA3uSEfGIwCIUXZcL+gSzpYcjDSDEKvFoDGCX2qk+d/B/IPvfMBmH9TEW1rMf6EX7HBBpoiQZSIZfmH4Ooe+vsHr7oSdhIXSmBWzoq1Je3CoSRfZoSkfHyavDnHe+wCBCEeL9WEzuczYEDyAltSLewbdBoQNZXSTAmX8xxfCFILrsBEeV3QOEgSeyWvR6H4mpwivoT0caX0rNjZv98Swonq9CP6zGWDSa1j0Hg5X55QLjv+m3Bo+p3Ck= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR00MB0432.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: db669dd2-6979-4c46-c812-08d81250304e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 23:51:28.8968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k69KAsUw2MPMD41W0puJLybtf6btWTCQF7NmB8GTywtjeiwu81VK/GrtZA3QJ+u9lcOCUZObezArxPgROG0vQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0383 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 23:51:32 -0000 That is an interesting idea Dale thank you, =20 The spirit of my proposal is something to help out specifically in the curr= ent call analytics environment, and is hopefully lightweight to implement. = That said, as I read through your email a couple questions came to mind. ".. token in the INVITE which would be recorded with the voicemail message = to the callee B." Should there be any assumption about unanswered calls 'always' going to voi= cemail? Perhaps its an exception case, but curious on folks' perspective o= n the assumption.=20 "...B's call-back could include a token that A could attach to future INVIT= Es to B as evidence that the call was approved by B and thus avoid being sp= am-filtered." Assuming there are many one-way calling relationships would storage/search = requirements for the tokens eventually outweigh the benefit? Best regards, Russ -----Original Message----- From: sipcore On Behalf Of Dale R. Worley Sent: Sunday, June 14, 2020 5:26 PM To: sipcore@ietf.org Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-= sipcore-ratingprovided-00 I don't know of this question is related to this draft, but reading about t= his draft brings it to mind: It seems like an ideal system would allow the= potentially-spam caller A to put some sort of token in the INVITE which wo= uld be recorded with the voicemail message to the callee B. Then if B want= ed to contact A, B could send an INVITE that includes the token, thus allow= ing A to process B's call as a continuation of the original call. Similarl= y, B's call-back could include a token that A could attach to future INVITE= s to B as evidence that the call was approved by B and thus avoid being spa= m-filtered. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Crussp%40microsoft= .com%7C13a9320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%= 7C0%7C0%7C637277775480546881&sdata=3D06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYz= xonGo6uS4%3D&reserved=3D0 From nobody Tue Jun 16 18:39:22 2020 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 D36003A0D04 for ; Tue, 16 Jun 2020 18:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIkEbCO_QEmF for ; Tue, 16 Jun 2020 18:39:19 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 AD03F3A0D03 for ; Tue, 16 Jun 2020 18:39:18 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id i4so270495pjd.0 for ; Tue, 16 Jun 2020 18:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Wfb2Wvea21OKBhw/P2KgbOqbkBIz4W8Dx9QTjHuwfR0=; b=jNuzxF5fW1XD/l61CR68N54uz869lGcVlOkaVK6VXU2PeR7L29DwviM0KM9+p8VDmi Yi5fbbK+flRD/+6s49AqpbTeeASkLZEpAO6zktR6SZ0nkh3+DyAY/llkdio2XL6j+YAK fxvtohmwfhYOszgmIR6v+g8H+K8kZcS6HVRSW6wk1UBqcjUQi47O6h5cZptHsbQ92wq/ E9iP46ZF/zkpurAzSXxtHxCtff1IrS4XlVovdgCljPz8kzXw8H+IJ+XZ5WVYGbHSM94o UDDURE7/Nzib3sfvdZUlv2OX+sJ9d7GLS1xwqOwQydpqtDQ6Pvq+f8h1R9dbXl4zFIcV WGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Wfb2Wvea21OKBhw/P2KgbOqbkBIz4W8Dx9QTjHuwfR0=; b=UPYUWZ7CdGwrRQGh8aVhyvu9OhBIvwME27UmHT4n7BN/oxQ01boDGB+iK56sev3cr4 /7tx6kkdysmDC0zo8v1ufmHQw6SlIPQAW9myAFt3HlF3s8rLmjt4GNVAZaBFFnxjqwaZ zKt9zd50XQ+/cPe5f1BE0tiDRir/TLOxef1MyYqhFImCynZEUMR3sVhTt/DGt9Ardms1 YnYgEF6JNBZb2+/MbUtGK7cmEJWCsN0w67kDjUyiuFb2adCgUou8R/aig/adqBLEOP8Z n5S9qDOXu7Voaz+etw1EUkT/vH6ZqDSEZ/ueeKipn4NrfeTPtVM/WDTRxoT+c+XWJnrf smiQ== X-Gm-Message-State: AOAM532bDZ2JxFer1Q2Tp33no9dCem3T44sfOyNGI2fc0F+UHBr2oftK 1yV3ICEoLGUCl8hYu6gIqBs= X-Google-Smtp-Source: ABdhPJzN2b91hCwukZ2I7pZKgGJDoyPXBBr22X3ovkxIJmFnrBJmdgcScZJEgh+iJJDUIaUBTj2DMg== X-Received: by 2002:a17:902:744b:: with SMTP id e11mr4375828plt.71.1592357957957; Tue, 16 Jun 2020 18:39:17 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id n4sm3599704pjt.48.2020.06.16.18.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 18:39:17 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Christer Holmberg , Roman Shpount References: Message-ID: <0aa32cec-2592-2e90-f9fa-37462ff63bd0@gmail.com> Date: Wed, 17 Jun 2020 10:39:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 01:39:21 -0000 HI, I noticed that there is a problem with this fix. According to this fix, a UAC can force the session timer to stop by attaching a SE header with refresher=uas to an UPDATE request. After all, I think it's Section 7.2 that should be fixed. Section 7.2 should says; Even if a UAC included a refresher=uas in a request, the UAC MUST be prepared to receive a refresher=uac in the response. This will happen when the UAS doesn't support the session timer extension and the proxy follows the procedures described in Section 8.2. Therefore, it is NOT RECOMMENDED that the refresher parameter be set to 'uas', unless the UAC knows that the other side supports the session timer. Regards, Shinji On 2020/06/08 13:18, OKUMURA Shinji wrote: > Hi, > > I think the following change is necessary. > > Section 8.2 says: > ======================================================================== >    If the proxy remembers >    that the UAC did not support the session timer either, the proxy >    forwards the response upstream normally. > ======================================================================== > > It should say: > ======================================================================== >    If the proxy remembers that the UAC did not support the session timer >    either or the value of the 'refresher' parameter was 'uas', the proxy >    forwards the response upstream normally. > ======================================================================== > > Regards, > Shinji From nobody Tue Jun 16 18:50:53 2020 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 E745E3A0D16 for ; Tue, 16 Jun 2020 18:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 IDpQHRoHfvC9 for ; Tue, 16 Jun 2020 18:50:50 -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 BA63C3A0D12 for ; Tue, 16 Jun 2020 18:50:50 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id lNCSjrx8GYbCIlNE0j4BrM; Wed, 17 Jun 2020 01:50:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1592358648; bh=HBWOcgKWucfeHL5C8RM+fWNLqVo8QI61IYPssszQwFM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=evuQFtJd61O2YjF4rBWfmFt6FPo69BS5YBdSU9U0+BtoEXjXaWB0zW0odeyNUVhZY 4bbgCVchE4I+t1rv+Ow3edPeRBI682YUjB4X3VVbhp1ZBnMf4shP4Uh5KR8NCIM62N DR0h8m0lkqmA7AwincfHjfIaA3kSnu9o/ExIrcMwToZ0x3XEG7JxlnGHtYIWKlqaLU T48P+NSP9YxN0IHZ/HhgOdG+5VpPZnaAHqGT+Bng0EzWDvdrRMXO9L7Q0EA2etvIsS 8UY+X8YxNGtAslpukQK99EDQaCZ7PzQvyP0WkvT6ZvfBISNrBKMv4qhyHb0H1uuqaG 0voc6M5LDy0tQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-20v.sys.comcast.net with ESMTPA id lNDzj6461ZcRQlNDzjP9rQ; Wed, 17 Jun 2020 01:50:48 +0000 X-Xfinity-VMeta: sc=0.00;st=legit 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 05H1okA7001358; Tue, 16 Jun 2020 21:50:46 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 05H1okEi001355; Tue, 16 Jun 2020 21:50:46 -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: Russ Penar Cc: sipcore@ietf.org In-Reply-To: (russp=40microsoft.com@dmarc.ietf.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 16 Jun 2020 21:50:45 -0400 Message-ID: <87r1ue4g0a.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 01:50:52 -0000 Russ Penar writes: > Assuming there are many one-way calling relationships would > storage/search requirements for the tokens eventually outweigh the > benefit? I think that storage would not be a problem, because in many cases tokens would not need to be stored. There is a trick which has been used in varous situations (and proposed in many SIP scenarios) where some sort of token is generated by some device that contains within the token a signature that attests that it was generated by that device. If a message is presented to the device that has a purported token, the device can verify the signature, rather than having to have a record of the tokens it has generated. For example, in this case, the callee could have a secret, large random string, and the token is the hash of the caller's From URI and the random string. The callee can give the token to the caller, and later the callee can verify that the token was the one it generated for this particular caller. Dale From nobody Tue Jun 16 18:51:40 2020 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 57EF93A0D14 for ; Tue, 16 Jun 2020 18:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUE3qOGos3f for ; Tue, 16 Jun 2020 18:51:38 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 35FF03A0D12 for ; Tue, 16 Jun 2020 18:51:38 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id 10so345372pfx.8 for ; Tue, 16 Jun 2020 18:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5xnqn8lkcrE1f6O8tlyJv9MrpQN/x/voOBuyKzuDsrw=; b=GCNzxFuXs+GwUfTYoI/RXItxhjYAVp8+bFYOxdVptuC/xARS5K0hWx8qjskUbhyvYg TaP1kQcsJIX5Urvqf4i2H8JUy4a4nIbhaq8w8VfG0+TE7l/7Bv0O/ZKO31lDGtFda98c id8/K+v/DYthTrL+HgWzW/H1juzT8GVCgKDPCTQ8h7KEFLHunlMnta9zffUDv/yfEu3w Dek7TCAdv/Wuejn6MoH4BooL6lOZ76jQ+Q+7Y7emKEqH+8R+gQmk1fgqr5e/y3yXD8Js DrBfFGBdho8ORwfciDl8nPruJsSLbvPKJ5nTbbvXbyNogzYXZhreLIZooM10+uxGXA3G p++g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5xnqn8lkcrE1f6O8tlyJv9MrpQN/x/voOBuyKzuDsrw=; b=kgWyrEg7zrWUcKcqg8qvfo+n5K29WcicDb3u/KZBOYsIZQhTyGT6xVes6IUyXm4hYV OMSamPQhtSsre9GP3d5mQg7zq/LL4T66aRB0Ckkjvw7GZ/A1BgowOLQbO9xgG/x8P0S7 R5XKW4I9heeGnUpOfyvlG+r46y4EcyUW5kqWn2yfjb2mg9oP9aMKkEojWcrkZhJEkMh9 rhM0Ubjph02jfScQmHElDfrdk0bN4/uqxlPFKNeTlQ9c/adxRP73qRBZWXBCbhgaEjQi 48P7uApiaGjFvVmQU9N3kHK4P6kvbsuP5QWaTai9JVuobvou6Br9loyZQZGvTxHK/29O rbJQ== X-Gm-Message-State: AOAM531faBNFsRT1q+A4+G1v+Qbc99I57+ZCnSUbiEJ/hZBP+RNo3tWd /QMMngu7xyUcOaZR8qTr3ik= X-Google-Smtp-Source: ABdhPJyMMfhEYuUIYV+MGvghog4dWSNPwkLymSMx/T/tmxNefpDo0S+sfoz7np+Xv/KJAPOqZm1UnQ== X-Received: by 2002:a62:7bd6:: with SMTP id w205mr4396407pfc.181.1592358697666; Tue, 16 Jun 2020 18:51:37 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id r8sm15896187pgn.19.2020.06.16.18.51.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 18:51:36 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Christer Holmberg , Roman Shpount References: <0aa32cec-2592-2e90-f9fa-37462ff63bd0@gmail.com> Message-ID: <5627c5ff-04b0-ca2c-a5cd-c1b7973e89f0@gmail.com> Date: Wed, 17 Jun 2020 10:51:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <0aa32cec-2592-2e90-f9fa-37462ff63bd0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : Bug in 8.2. Processing of Responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 01:51:39 -0000 Hi, This forced "turned-off" occurs when the UAS does not support the session-timer. On 2020/06/17 10:39, OKUMURA Shinji wrote: > HI, > > I noticed that there is a problem with this fix. According to this fix, a UAC can force the session timer to stop by attaching a SE header with refresher=uas to an UPDATE request. After all, I think it's Section 7.2 that should be fixed. > > Section 7.2 should says; > > Even if a UAC included a refresher=uas in a request, the UAC MUST be prepared to receive a refresher=uac in the response. This will happen when the UAS doesn't support the session timer extension and the proxy follows the procedures described in Section 8.2. Therefore, it is NOT RECOMMENDED that the refresher parameter be set to 'uas', unless the UAC knows that the other side supports the session timer. > > Regards, > Shinji > > On 2020/06/08 13:18, OKUMURA Shinji wrote: >> Hi, >> >> I think the following change is necessary. >> >> Section 8.2 says: >> ======================================================================== >>     If the proxy remembers >>     that the UAC did not support the session timer either, the proxy >>     forwards the response upstream normally. >> ======================================================================== >> >> It should say: >> ======================================================================== >>     If the proxy remembers that the UAC did not support the session timer >>     either or the value of the 'refresher' parameter was 'uas', the proxy >>     forwards the response upstream normally. >> ======================================================================== >> >> Regards, >> Shinji From nobody Tue Jun 16 19:28:46 2020 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 313393A0DAE for ; Tue, 16 Jun 2020 19:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 uLJkeEcwBLVQ for ; Tue, 16 Jun 2020 19:28:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770079.outbound.protection.outlook.com [40.107.77.79]) (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 EA25B3A0DAF for ; Tue, 16 Jun 2020 19:28:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MRdeK976huaC0yR5qULUtFVG2yIJX9e4ebNJXiGprfCBLUhxmxirge/sqQ8eAdimlDXegfpPPl/7yMZAb43Yp2s1sck/v4airvGxOBLD9LeVlIwoK+k6E02uXcI90j6QtH/Lj7WyxYDH7Izj4d7oZ+V86/MbxBymJHeTzxxTZssae+gZBMCUS4wb9c3j1zZReGe/99dJtK6ihSW6fgXaLkH9DzdkCroCNSS9ZlgYiU+MZqxGfUqpmsaB+1MW+pqmoiFYhwa3FM8z68kc+fPP0WpZq0eDeWskf9mb6qEBB3i1GDDLpXSMcH9orgr/BFpZs3h7cnaHqJbnaTNN+9QrsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=776aaxYVrGxm4sdHTeeRJ5uqZEyE5IY2jpbTV5cCsjk=; b=UGskbrJmiCN5hiyUUMIKbxQ68/kHpSfMtnRglnEEV9IbrKuELxLB4wLtavuCk0I4Mi3BvjgpxGJs5+Wf7AntDWrbofL22TB3B/JVDQYizmLkXtFthnxvmD6pDZIKq5vAWYxxaGoYQ+2WFgK7Nvt1taOAZqJ+CAfHib9AJHo4YQ0BQXEhdUg+jw4hD0cJzflUqVDtBUA/i2+gOjFIyFOTDQQ9PfvyqC/Ks37T38epxb9ag4h6ctOuLGNxavVNDjdxXhy634IZ/B2UhCcpK6oC0il1oObojXnlocb8qZBA7K+doru9n4M5M0bZokb6r6FzDpKIR0sd9vWcMJ/yYex+dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=776aaxYVrGxm4sdHTeeRJ5uqZEyE5IY2jpbTV5cCsjk=; b=Ho/TWkogn/CauL6Zfvp6/2EA2iJhFG6iwTI/Qfq3arZHTV9OaXmJjdtMCdfGYtmxS1DTfy5t4jRGxi8SrRZOZ6rBliHc9VMNeS0Bfu7tS1QCrZc6/5eDsqmgLdx2kYuSJhPBgLC2l0mjbH0hjpzgN91E1vBvAMmwasV8bHzm25Y= Received: from SN4PR0501CA0016.namprd05.prod.outlook.com (2603:10b6:803:40::29) by DM5PR1201MB0267.namprd12.prod.outlook.com (2603:10b6:4:55::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Wed, 17 Jun 2020 02:28:41 +0000 Received: from SN1NAM02FT023.eop-nam02.prod.protection.outlook.com (2603:10b6:803:40:cafe::e0) by SN4PR0501CA0016.outlook.office365.com (2603:10b6:803:40::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10 via Frontend Transport; Wed, 17 Jun 2020 02:28:41 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT023.mail.protection.outlook.com (10.152.72.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 17 Jun 2020 02:28:40 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05H2ScQN028530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 16 Jun 2020 22:28:39 -0400 To: sipcore@ietf.org References: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> <87blll5g5f.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <4075db39-a51f-50be-33a0-71dfb8ecaf26@alum.mit.edu> Date: Tue, 16 Jun 2020 22:28:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(376002)(396003)(39860400002)(346002)(46966005)(8936002)(31696002)(8676002)(31686004)(77540400001)(47076004)(53546011)(2906002)(70586007)(70206006)(82740400003)(75432002)(86362001)(6916009)(478600001)(186003)(786003)(956004)(2616005)(5660300002)(83380400001)(36906005)(336012)(356005)(7596003)(82310400002)(316002)(26005)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3c3f3af1-9683-42c9-a708-08d812662618 X-MS-TrafficTypeDiagnostic: DM5PR1201MB0267: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04371797A5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WyfWICWNxFldtzRPVhQl8ye+eLW/gtUhVMe8reMpdZZcp5CETyMIycC1x8JrdnBEiqckgjFK/srcd4RnIWS+s3RsSXxKrcxjh+rsHyapgbRBa3JBR4L6T+WHEkLTwxrh+DgZb7rAHTSa3dHFx381ZZRsEUCJaveeetBH80Wo93jWizzu/0wWANICIPmJWw7ZgS7ltomAZntUNcLeXHlCAXG2eYxqJTzOfdWXjKU3xNDpb5R/MSz60WFk2G3d8LDWO7/QUnnujkDJOAfXQ1/9TWj1v/+nNyLO51CyNtBJmJNYobpEtuBn4im3MGzpc5t9D9S6DBRqWpqlrRlaav4hOhONCv3WmkJViRqL1OJExtnqhnInS065ofdMHWoVHk6JuN/oiF8UkBNMDNW93IB/tjPXbwBjlsh1/1uoGLLyQe8= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2020 02:28:40.6230 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3c3f3af1-9683-42c9-a708-08d812662618 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB0267 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 02:28:44 -0000 On 6/16/20 7:51 PM, Russ Penar wrote: > That is an interesting idea Dale thank you, > > The spirit of my proposal is something to help out specifically in the current call analytics environment, and is hopefully lightweight to implement. That said, as I read through your email a couple questions came to mind. > > ".. token in the INVITE which would be recorded with the voicemail message to the callee B." > > Should there be any assumption about unanswered calls 'always' going to voicemail? Perhaps its an exception case, but curious on folks' perspective on the assumption. I think there are all variety of ways that people handle unanswered calls, even if the default for most service providers is voicemail. And in any case there are *many* people who have full mailboxes and so don't have additional calls recorded. So I don't think you should assume you can count of voicemail to deliver an announcement. (Nor do I think there is any obligation to deliver announcements to callers who have not made any effort to learn of them.) Thanks, Paul From nobody Tue Jun 16 19:36:29 2020 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 AA4AD3A0DC0 for ; Tue, 16 Jun 2020 19:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 jECJgZFCxHBe for ; Tue, 16 Jun 2020 19:36:26 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 961FE3A0DCA for ; Tue, 16 Jun 2020 19:36:26 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id lNuLjiQAiHBASlNw9j9H9B; Wed, 17 Jun 2020 02:36:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1592361385; bh=xckUaqoIE/Gd0E2xBLDecY52SWTs5XehuOI8yCeeQy8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=lWO6Z1ye7tpNpwbS9FRJB84Tf1XvW8YsG26OKqTawKd8GjWTEyx7Im+8MDO+miLh8 QRmaATxX/DA3oaKP5NOa9fxojeXhPRb3TYX6jZVsUgDtjJdMMSq7GciNisBnM/LLjK KMQ4JB3w1g55fayXgAkJncYBUiVNAnb5llPAl8Y2WqtIN+uDkfcN5ySI/0S85cNeoc zhjS+XvWCeiaVhU/krUJ02dhnZgkSDxbieyKr6Nno+TdQ/YU9GprOtgeI8e9Hxktl4 /cQijV8QUH9SvR6MFr7HBzTUU5uekedMtXU6ypgZ7g6/CWkskFJwhUr8mjODeO4kSn asMkf2wLZA5tA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id lNw7jghF545YFlNw8jZEsW; Wed, 17 Jun 2020 02:36:25 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit 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 05H2aNe0005419; Tue, 16 Jun 2020 22:36:23 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 05H2aMlU005405; Tue, 16 Jun 2020 22:36: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: Maxim Sobolev Cc: sipcore@ietf.org, russp=40microsoft.com@dmarc.ietf.org In-Reply-To: (sobomax@sippysoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 16 Jun 2020 22:36:22 -0400 Message-ID: <87lfkm4dw9.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 02:36:28 -0000 Maxim Sobolev writes: > That actually a great idea Dale, I was thinking along the same lines > yesterday but dismissed the idea as too extravagant. Nobody prevents > multiparty body to carry on both "Rating" and media description! On the > implementation side of things, handling multiparty in 183 would be way less > expensive proposition, compared to adding new class of status codes. IMHO. In regard to multipart bodies, I would worry that some UAs would not look within them to find the SDP. But it seems intrinsic to your use case that the rating will be generated before a session description is -- the rating will be generated before the INVITE is allowed to reach a UA. Dale From nobody Wed Jun 17 02:37:03 2020 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 5B8C53A087D for ; Wed, 17 Jun 2020 02:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.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 Ns2dAzPS4qz8 for ; Wed, 17 Jun 2020 02:37:00 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (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 AE0623A0873 for ; Wed, 17 Jun 2020 02:37:00 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 464BC20425 for ; Wed, 17 Jun 2020 09:36:59 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=HhVHOvRE2lNVkdAT3h78LJz6ubkuoANRmjqxdMHCkp8=; b=hgAJiOKTnLZb2DZNDn0vKnOq5BDwqnKUtgyDHSb7PxgevpCjMLnsWAOqoMgCh3c+4uH9jqGw/CWANrtM094xcCxkhN8cOTvaH60P4xMLsDCyxX88jZwgqXq1dWfgJLMxyFX6L9iqkEOWpLtiKN4b3APfgLjmiEPyAb2MkDR58LOVZmOCGkQkqpibzPMITjRIpJbALiBIjo7SHKdMx5GzICvsS30VqVTDn2JghDnDgDCmkupSodpOZQASpOpX7Q+OKdQB+2OwIYh4ts6esfGlPNJD4UbUOiO8P5+vx1p5PcHF+uoyJweVqBnr4UKygITvodvjUYEHIt7LDWHIByQclQ== Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Wed, 17 Jun 2020 09:36:58 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 48) id 5803DA1D187; Wed, 17 Jun 2020 09:36:58 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 17 Jun 2020 15:36:57 +0600 To: "Russ Penar" , "Dale R. Worley" , sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: References: <5F7515C2-C8EB-4BEC-B4B0-4D82CABE64FA@employees.org> (caryfitz@employees.org)<87blll5g5f.fsf@hobgoblin.ariadne.com> Content-Type: multipart/alternative; boundary="=_2a36a08a22ab4b49b78e8827b2513b70" Message-Id: <20200617093658.5803DA1D187@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 09:37:02 -0000 --=_2a36a08a22ab4b49b78e8827b2513b70 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" In India no Cell provider provides voice mail services. An announcement is provided "Callee is not answering." and call is disconnected. ThanksSamir On 6/17/2020 at 5:21 AM, "Russ Penar" wrote:That is an interesting idea Dale thank you, The spirit of my proposal is something to help out specifically in the current call analytics environment, and is hopefully lightweight to implement. That said, as I read through your email a couple questions came to mind. ".. token in the INVITE which would be recorded with the voicemail message to the callee B." Should there be any assumption about unanswered calls 'always' going to voicemail? Perhaps its an exception case, but curious on folks' perspective on the assumption. "...B's call-back could include a token that A could attach to future INVITEs to B as evidence that the call was approved by B and thus avoid being spam-filtered." Assuming there are many one-way calling relationships would storage/search requirements for the tokens eventually outweigh the benefit? Best regards, Russ -----Original Message----- From: sipcore On Behalf Of Dale R. Worley Sent: Sunday, June 14, 2020 5:26 PM To: sipcore@ietf.org Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 I don't know of this question is related to this draft, but reading about this draft brings it to mind: It seems like an ideal system would allow the potentially-spam caller A to put some sort of token in the INVITE which would be recorded with the voicemail message to the callee B. Then if B wanted to contact A, B could send an INVITE that includes the token, thus allowing A to process B's call as a continuation of the original call. Similarly, B's call-back could include a token that A could attach to future INVITEs to B as evidence that the call was approved by B and thus avoid being spam-filtered. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=02%7C01%7Crussp%40microsoft.com%7C13a9320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277775480546881&sdata=06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYzxonGo6uS4%3D&reserved=0 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --=_2a36a08a22ab4b49b78e8827b2513b70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" In = India no Cell provider provides voice mail services. An announcement is pro= vided "Callee is not answering." and call is disconnected.

Thanks
Samir

On 6/17/2020 at 5:21 AM, "Russ Penar"= <russp=3D40microsoft.com@dmarc.ietf.org> wrote:
That is an = interesting idea Dale thank you,

The spirit of my proposal is some= thing to help out specifically in the current call analytics environment, a= nd is hopefully lightweight to implement. That said, as I read through you= r email a couple questions came to mind.

".. token in the INVITE whi= ch would be recorded with the voicemail message to the callee B."

Sh= ould there be any assumption about unanswered calls 'always' going to voice= mail? Perhaps its an exception case, but curious on folks' perspective on = the assumption.

"...B's call-back could include a token that A coul= d attach to future INVITEs to B as evidence that the call was approved by B= and thus avoid being spam-filtered."

Assuming there are many one-wa= y calling relationships would storage/search requirements for the tokens ev= entually outweigh the benefit?

Best regards,
Russ

-----Ori= ginal Message-----
From: sipcore <sipcore-bounces@ietf.org> On Beh= alf Of Dale R. Worley
Sent: Sunday, June 14, 2020 5:26 PM
To: sipcore= @ietf.org
Subject: [EXTERNAL] Re: [sipcore] please review and comment on= draft-penar-sipcore-ratingprovided-00

I don't know of this question= is related to this draft, but reading about this draft brings it to mind: = It seems like an ideal system would allow the potentially-spam caller A to= put some sort of token in the INVITE which would be recorded with the voic= email message to the callee B. Then if B wanted to contact A, B could send= an INVITE that includes the token, thus allowing A to process B's call as = a continuation of the original call. Similarly, B's call-back could includ= e a token that A could attach to future INVITEs to B as evidence that the c= all was approved by B and thus avoid being spam-filtered.

Dale
_______________________________________________
sipcore mailing listsipcore@ietf.org
https://nam= 06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Crussp%40microsoft.com%7C13a9= 320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C6= 37277775480546881&sdata=3D06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYzxonGo6uS4%3= D&reserved=3D0

_____________________________________________= __
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipc= ore
--=_2a36a08a22ab4b49b78e8827b2513b70-- From nobody Thu Jun 18 02:48:12 2020 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 C0D683A11CB for ; Thu, 18 Jun 2020 02:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTiIjWxBL2gj for ; Thu, 18 Jun 2020 02:48:08 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4E91F3A11CA for ; Thu, 18 Jun 2020 02:48:08 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id y18so2227069plr.4 for ; Thu, 18 Jun 2020 02:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=QsnZ1s5huIQXXc0e+hw6Qs5Le7qt9HzibSOgsWOlktQ=; b=n2N9XjIBtBvM9WL6zEPlg8MyS2AluPCRk2ag3rVkGTOt8tUE9frfmEHeT0yD2+J3fl C4usX+UqESq8sMCeYEw1T/7y6K7SnHwg7T8m3aaAueQnPoSaB7tFK7gkFUhaPYUmi9k5 8LhQzgYApb1hTH82qBFQD/cp9m/T0mawtVkkRN+CqtQM/owL5o4POQ38phukvis215jH 5Yed1eNz/fgq5HbIX/rSKmbUWfBWwbh/9T6HyXXIcsLt20IVVRQuHEXztwVpHMTxWpdO Zx7k98WmjwivqV7ZjQmVwBru2AA/CexoNkfJSLz1nE0xwcEzgqmWFtOFjZ2izaciUYWn 5Y3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=QsnZ1s5huIQXXc0e+hw6Qs5Le7qt9HzibSOgsWOlktQ=; b=jrOc2MXBA4ViSIem+VVqTn7NZput3qc5j21JNIta/BZCWnK1PR3Ytx0hcTO7sCkrE+ GUBjQrIeU0ooGAtisw0TnAqKjAWw3GYEw6TGNIiEvumZS4O6+x2jO93Dxnq4xSQd1qOA BiKWsetKc9n8wOz1WQ75xvOUb91ndktP61wax30rYFOaUGmilJeGN9K2BT4wXPGHzH9P CzB6VuVwZkIcTnfe6b5cfVzaZWVxUILGnWI5gnyC/VhaZ4ikYF2npfVyiYr0Cex2vQph h294dhQWZ5QokBfrujRDkVaAHv6KFIJh+hF/nrtGyap9KN6igY3Kum65LTR3I2huPliQ Mzlg== X-Gm-Message-State: AOAM531kousgseVKZ7aA/BG3S9tkUFre1Y8vV8Fi9UGAkHekrEzEhzl2 /6vSRiE820FzidiC/Jhko3E= X-Google-Smtp-Source: ABdhPJw0hv0gK2xaLpHTAikVHVSbzeli3+8qus0sRbZlPkeroDX++ZK/yHr7nrnXXAypq+cTGe39tQ== X-Received: by 2002:a17:90a:ad87:: with SMTP id s7mr3522427pjq.225.1592473687692; Thu, 18 Jun 2020 02:48:07 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id a17sm2368549pfi.203.2020.06.18.02.48.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 02:48:06 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Message-ID: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> Date: Thu, 18 Jun 2020 18:48:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 09:48:10 -0000 Christer, Will you apply the following solutions to bis? draft-ietf-sipcore-sessiontimer-race-02 1.2. Solution This document updates [RFC4028], by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] session timer mechanism [RFC4028]. The following clarifications are provided: o A Session-Expires header field can only be included in a session refresh request if there is no ongoing negotiation of usage of the session timer mechanism, and if there is no ongoing INVITE transaction. o A user agent shall, if it receives a session refresh request with a Session-Expires header field during an ongoing negotiation of usage of the session timer mechanism, or when there is an ongoing INVITE transaction, send a 491 (Request Pending) response to the request. o The absence of a Session-Expires header field in a response will disable usage of the session timer mechanism only if the associated request contained a Session-Expires header field. Assuming all entities(UAC, UAS and proxies) keep a consistent policy for their own session-timer, even if transactions conflict, I think the results are also consistent. Does the request still need to be reject with 491 in spite of no glare? And an UPDATE request is used for updating a remote-target-uri as well as the session timer. Should UAs reject the UPDATE? Regards, Shinji From nobody Sun Jun 21 13:03:10 2020 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 DE02F3A084E for ; Sun, 21 Jun 2020 13:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 GEcNQCfGbIxC for ; Sun, 21 Jun 2020 13:03:07 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.65.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444E23A084C for ; Sun, 21 Jun 2020 13:03:07 -0700 (PDT) Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 38371400CCA23 for ; Sun, 21 Jun 2020 13:42:48 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id n6BGjBb4bXGIkn6BGjh6wV; Sun, 21 Jun 2020 15:03:06 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6nm+njZ0RSOwGvuMaHruW90snG+5eX0dOgJVdykji3A=; b=HG4xVkCIRGcdASmq9u2wxfc2PK /Ina1yYehdsP1xTC4Z7fGqPs9PygXuWvqpT0pP1+DxdiMnU7GDlyE17f8QOcPrFZ/AttTfpBrx4Zc wRBwcPGLOR1NjEYp/sLiR6d1X; Received: from pool-100-36-40-24.washdc.fios.verizon.net ([100.36.40.24]:57646 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from ) id 1jn6BG-002aMK-Eh; Sun, 21 Jun 2020 14:03:06 -0600 User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Sun, 21 Jun 2020 16:03:04 -0400 From: Richard Shockey To: Russ Penar , "Dale R. Worley" , "sipcore@ietf.org" Message-ID: <5D3B2CCC-4801-4DB8-89A4-D29ED628669D@shockey.us> Thread-Topic: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.24 X-Source-L: No X-Exim-ID: 1jn6BG-002aMK-Eh X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-24.washdc.fios.verizon.net ([192.168.1.156]) [100.36.40.24]:57646 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 20:03:09 -0000 I really like this idea as well.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 6/16/20, 7:51 PM, "sipcore on behalf of Russ Penar" wrote: That is an interesting idea Dale thank you, =20 The spirit of my proposal is something to help out specifically in the = current call analytics environment, and is hopefully lightweight to implemen= t. That said, as I read through your email a couple questions came to mind. ".. token in the INVITE which would be recorded with the voicemail mess= age to the callee B." Should there be any assumption about unanswered calls 'always' going to= voicemail? Perhaps its an exception case, but curious on folks' perspectiv= e on the assumption.=20 "...B's call-back could include a token that A could attach to future I= NVITEs to B as evidence that the call was approved by B and thus avoid being= spam-filtered." Assuming there are many one-way calling relationships would storage/sea= rch requirements for the tokens eventually outweigh the benefit? Best regards, Russ -----Original Message----- From: sipcore On Behalf Of Dale R. Worley Sent: Sunday, June 14, 2020 5:26 PM To: sipcore@ietf.org Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-pe= nar-sipcore-ratingprovided-00 I don't know of this question is related to this draft, but reading abo= ut this draft brings it to mind: It seems like an ideal system would allow = the potentially-spam caller A to put some sort of token in the INVITE which = would be recorded with the voicemail message to the callee B. Then if B wan= ted to contact A, B could send an INVITE that includes the token, thus allow= ing A to process B's call as a continuation of the original call. Similarly= , B's call-back could include a token that A could attach to future INVITEs = to B as evidence that the call was approved by B and thus avoid being spam-f= iltered. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Crussp%40microsoft.= com%7C13a9320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%7C= 0%7C0%7C637277775480546881&sdata=3D06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYzxonGo= 6uS4%3D&reserved=3D0 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Jun 21 15:37:39 2020 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 DCA3B3A07CE for ; Sun, 21 Jun 2020 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 yaT2rQ1gi6vP for ; Sun, 21 Jun 2020 15:37:36 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.55.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22753A07B1 for ; Sun, 21 Jun 2020 15:37:35 -0700 (PDT) Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 6C4CB400C5923 for ; Sun, 21 Jun 2020 16:17:16 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id n8aljTiPnwgQAn8alj0dP4; Sun, 21 Jun 2020 17:37:35 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VuhIbBxdiz544rcAYdM63UTOt5K+RQ79FoI+xGDcD1w=; b=mPd4VDizyk2YBRh4GM+hRit2cO LlK1vU/zNLAvELRK4jqUiVfURouQhQsswaQbkHX+0KTfA2iGsOVkqyhRhiiuNW2JBeLvp5zZ7H1px d2A2aI8HJ5LUVLIPOmAvLub/I; Received: from pool-100-36-40-24.washdc.fios.verizon.net ([100.36.40.24]:59447 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from ) id 1jn8al-003WWJ-1V for sipcore@ietf.org; Sun, 21 Jun 2020 16:37:35 -0600 User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Sun, 21 Jun 2020 18:37:34 -0400 From: Richard Shockey To: "sipcore@ietf.org" Message-ID: <54D854A7-1A68-4F2A-8CC7-04AD3EA3730B@shockey.us> Thread-Topic: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 References: <5D3B2CCC-4801-4DB8-89A4-D29ED628669D@shockey.us> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.24 X-Source-L: No X-Exim-ID: 1jn8al-003WWJ-1V X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-24.washdc.fios.verizon.net ([192.168.1.156]) [100.36.40.24]:59447 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 22:37:38 -0000 The real advantage here is the use case only looks like a BCP and we don=E2=80=99= t get trapped into the endless fight over a new SIP response code. This is in perfect alignment with RFC 8688 aka the SIP 608 rejected error c= ode. If SP's want to use it fine if they don't OK but I do know what the re= gulators might think.=20 And yours truly will be dealing with that tommrrow.=20 https://www.sipforum.org/news-events/stir-shaken-virtual-summit/schedule/ =20 For the rest of you folks we do know what the use case is it=E2=80=99s the US TRA= CED act. We have a legislative mandate and its going to be enforced. It als= o might push forward the issue of all IP interconnection. =20 Film at 11.=20 IMHO this needs to get formalized in SIPCORE ASAP. I think Russ needs to w= eigh his options here and lets keep the discussion going but I'll certainly = support some kind of draft along these lines as a formal SIPCORE WG item. = There is no need to go to DISPATCH on this.=20 As for something catchy .. CREAM really ? Where is the liquor component. A= ll new SIP protocols or extentions MUST have a reference to booze or James B= ond.=20 =EF=BB=BFOn 6/21/20, 4:47 PM, "Gorman, Pierce A [CTO]" wrote: Me too! End entities exchanging information elements that could be used to auth= enticate and authorize a communications attempt sounds good to me. We need = a catchy acronym. I'll volunteer SIGNET. Hmmm, on second thought, since it's based on SIP, maybe we should use C= REAM; Communications Relationship Extensible Address Method. https://access.atis.org/apps/group_public/document.php?document_id=3D4329= 5 See slide #8. Pierce -----Original Message----- From: sipcore On Behalf Of Richard Shockey Sent: Sunday, June 21, 2020 3:03 PM To: Russ Penar ; Dale R. Worley <= worley@ariadne.com>; sipcore@ietf.org Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draf= t-penar-sipcore-ratingprovided-00 I really like this idea as well.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum https://nam01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.sh= ockey.us%2F&data=3D02%7C01%7Cpierce.gorman%40sprint.com%7Cf7486b9afdd0449d= 39eb08d8161e2514%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C63728366601758= 7982&sdata=3D8ju5zVIGSCJAkS5yEAy%2B8vbwBP5oLPuNq1haHwIQ1pQ%3D&reserved= =3D0 https://nam01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.si= pforum.org%2F&data=3D02%7C01%7Cpierce.gorman%40sprint.com%7Cf7486b9afdd044= 9d39eb08d8161e2514%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C637283666017= 587982&sdata=3DOTxGsVDk9ua3fyaPy5y8t%2Fy8lGlWlJ8FtxyoXdNiLbI%3D&reserv= ed=3D0 richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =EF=BB=BFOn 6/16/20, 7:51 PM, "sipcore on behalf of Russ Penar" wrote: That is an interesting idea Dale thank you, =20 The spirit of my proposal is something to help out specifically in = the current call analytics environment, and is hopefully lightweight to impl= ement. That said, as I read through your email a couple questions came to m= ind. ".. token in the INVITE which would be recorded with the voicemail = message to the callee B." Should there be any assumption about unanswered calls 'always' goin= g to voicemail? Perhaps its an exception case, but curious on folks' perspe= ctive on the assumption.=20 "...B's call-back could include a token that A could attach to futu= re INVITEs to B as evidence that the call was approved by B and thus avoid b= eing spam-filtered." Assuming there are many one-way calling relationships would storage= /search requirements for the tokens eventually outweigh the benefit? Best regards, Russ -----Original Message----- From: sipcore On Behalf Of Dale R. Worle= y Sent: Sunday, June 14, 2020 5:26 PM To: sipcore@ietf.org Subject: [EXTERNAL] Re: [sipcore] please review and comment on draf= t-penar-sipcore-ratingprovided-00 I don't know of this question is related to this draft, but reading= about this draft brings it to mind: It seems like an ideal system would al= low the potentially-spam caller A to put some sort of token in the INVITE wh= ich would be recorded with the voicemail message to the callee B. Then if B= wanted to contact A, B could send an INVITE that includes the token, thus a= llowing A to process B's call as a continuation of the original call. Simil= arly, B's call-back could include a token that A could attach to future INVI= TEs to B as evidence that the call was approved by B and thus avoid being sp= am-filtered. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Cpierce.gorman%= 40sprint.com%7Cf7486b9afdd0449d39eb08d8161e2514%7C4f8bc0acbd784bf5b55f1b3130= 1d9adf%7C0%7C0%7C637283666017587982&sdata=3DBpZlh%2FaK5Z4ixZ9s0kk91hL71J%2= FCpYg%2BCuXE8UQ2gSk%3D&reserved=3D0 _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Cpierce.gorman%= 40sprint.com%7Cf7486b9afdd0449d39eb08d8161e2514%7C4f8bc0acbd784bf5b55f1b3130= 1d9adf%7C0%7C0%7C637283666017587982&sdata=3DBpZlh%2FaK5Z4ixZ9s0kk91hL71J%2= FCpYg%2BCuXE8UQ2gSk%3D&reserved=3D0 _______________________________________________ sipcore mailing list sipcore@ietf.org https://nam01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fsipcore&data=3D02%7C01%7Cpierce.gorman%40sp= rint.com%7Cf7486b9afdd0449d39eb08d8161e2514%7C4f8bc0acbd784bf5b55f1b31301d9a= df%7C0%7C0%7C637283666017587982&sdata=3DBpZlh%2FaK5Z4ixZ9s0kk91hL71J%2FCpY= g%2BCuXE8UQ2gSk%3D&reserved=3D0 From nobody Sun Jun 21 23:44:41 2020 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 18C6E3A0977 for ; Sun, 21 Jun 2020 23:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ubeaOTB7IkGa for ; Sun, 21 Jun 2020 23:44:38 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 78F743A096E for ; Sun, 21 Jun 2020 23:44:38 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id d4so12222466otk.2 for ; Sun, 21 Jun 2020 23:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UvKg6tDZJtPWlOsU+v+kaEL6lYAKULf2yL05vAPokmI=; b=KcEvxDQM/NUMmSMeUHtncH0jrUtwuEQhi02jF168Mo+4H+S7+pBABs0Drq/7gY2Vy7 xQDvo7MtcyBolbIJcbwd/P4DjRI0JDV55Avqur98vWm9I3b6RiLiKa8r1BdQ7MP48aA4 qOfjXMpacotG/nyDKYee8lF0tXKFe/Rb9/TH14O8C9EjOuSPOw3qflL0XbfTNSpnvWTU yM27rtlwkhoblBFLNySxnorQzo67JtfVzhTs6BhS9LW0KWrFonIAhucAh32dcTaZULHV NucOW4P8Yx5YuYJ6tZdaDgXLmUXdPEsiAv+eXQgRdDOcUUA0L/7g7HT7+PQVyBzeyElv 08Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UvKg6tDZJtPWlOsU+v+kaEL6lYAKULf2yL05vAPokmI=; b=KnUnrGuy5m4x3SIUqinWUoi9tvk1B5qsBoHeJW4KVbfYEpta8EPms/zTeyGkNyGX/u L/XkK1r6BPcSMg192E13rxtU8Ni/6typndSWFZYD1s63DTERPMxQ7MMT5wyzoruaBXQW 1yteuqlOq4AVk0aNEQpVZY+Yq0r0OIuY2OKVeLRNV/ktzxrYWC+G43a9WFcWdY3D5yK7 SUbgYaPLXxFKM0NY/NT7K+kV3smEEc4yK9EfdCf6LkBYQJ8unwghW2/6SXBbM/75oY5F Uj4T9fjSUXKuoB8Ac6l+yCOA3rL6SF247LOb84m5niXTmS5OAuqCcK1YkZJ8qHTOuEs6 IRWw== X-Gm-Message-State: AOAM530rpsIjzeCfKy0rENCNxrOC7jipTLQYlECjK6Z8yV0rGX4CRtb+ sB4WEjrGh+woptP3oXzMLvwefYY1OII= X-Google-Smtp-Source: ABdhPJy1TTKPMBtl4vz/LDrei19XB4BosaMz5EKc+6hc4C256WEzCR9tQinYu5Ajp/auUsflFc6+jg== X-Received: by 2002:a9d:1722:: with SMTP id i34mr11845693ota.6.1592808277335; Sun, 21 Jun 2020 23:44:37 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id x10sm3131157otp.32.2020.06.21.23.44.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jun 2020 23:44:36 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id u23so12197690otq.10 for ; Sun, 21 Jun 2020 23:44:35 -0700 (PDT) X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr12280951otr.13.1592808275390; Sun, 21 Jun 2020 23:44:35 -0700 (PDT) MIME-Version: 1.0 References: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> In-Reply-To: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> From: Roman Shpount Date: Mon, 22 Jun 2020 02:44:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000073390605a8a693e1" Archived-At: Subject: Re: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 06:44:40 -0000 --00000000000073390605a8a693e1 Content-Type: text/plain; charset="UTF-8" This is broken and not the solution for the session timer collision problem. Session-Expires is inserted by proxies. Proxies cannot reliably determine that another transaction is in progress. UA refusing session expires if another transaction is in progress will break existing implementations. _____________ Roman Shpount On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji wrote: > Christer, > > Will you apply the following solutions to bis? > > draft-ietf-sipcore-sessiontimer-race-02 > 1.2. Solution > > This document updates [RFC4028], by clarifying the procedures for > negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] > session timer mechanism [RFC4028]. The following clarifications are > provided: > > o A Session-Expires header field can only be included in a session > refresh request if there is no ongoing negotiation of usage of the > session timer mechanism, and if there is no ongoing INVITE > transaction. > o A user agent shall, if it receives a session refresh request with a > Session-Expires header field during an ongoing negotiation of > usage of the session timer mechanism, or when there is an ongoing > INVITE transaction, send a 491 (Request Pending) response to the > request. > o The absence of a Session-Expires header field in a response will > disable usage of the session timer mechanism only if the > associated request contained a Session-Expires header field. > > Assuming all entities(UAC, UAS and proxies) keep a consistent policy for > their own session-timer, even if transactions conflict, I think the results > are also consistent. > Does the request still need to be reject with 491 in spite of no glare? > And an UPDATE request is used for updating a remote-target-uri as well as > the session timer. > Should UAs reject the UPDATE? > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000073390605a8a693e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is broken=C2=A0and not the solution for the session t= imer collision=C2=A0problem.=C2=A0

Session-Expires is in= serted by proxies. Proxies cannot reliably determine that another transacti= on is in progress. UA refusing session expires if another transaction is in= progress will break existing implementations.
___= __________
Roman Shpount


On Thu, Jun 18, 2020 at 5:= 48 AM OKUMURA Shinji <ietf.shin= ji@gmail.com> wrote:
Christer,

Will you apply the following solutions to bis?

draft-ietf-sipcore-sessiontimer-race-02
1.2.=C2=A0 Solution

=C2=A0 =C2=A0 This document updates [RFC4028], by clarifying the procedures= for
=C2=A0 =C2=A0 negotiating usage of the Session Initiation Protocol (SIP) [R= FC3261]
=C2=A0 =C2=A0 session timer mechanism [RFC4028].=C2=A0 The following clarif= ications are
=C2=A0 =C2=A0 provided:

=C2=A0 =C2=A0 o=C2=A0 A Session-Expires header field can only be included i= n a session
=C2=A0 =C2=A0 =C2=A0 =C2=A0refresh request if there is no ongoing negotiati= on of usage of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0session timer mechanism, and if there is no ongo= ing INVITE
=C2=A0 =C2=A0 =C2=A0 =C2=A0transaction.
=C2=A0 =C2=A0 o=C2=A0 A user agent shall, if it receives a session refresh = request with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0Session-Expires header field during an ongoing n= egotiation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0usage of the session timer mechanism, or when th= ere is an ongoing
=C2=A0 =C2=A0 =C2=A0 =C2=A0INVITE transaction, send a 491 (Request Pending)= response to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0request.
=C2=A0 =C2=A0 o=C2=A0 The absence of a Session-Expires header field in a re= sponse will
=C2=A0 =C2=A0 =C2=A0 =C2=A0disable usage of the session timer mechanism onl= y if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0associated request contained a Session-Expires h= eader field.

Assuming all entities(UAC, UAS and proxies) keep a consistent policy for th= eir own session-timer, even if transactions conflict, I think the results a= re also consistent.
Does the request still need to be reject with 491 in spite of no glare?
And an UPDATE request is used for updating a remote-target-uri as well as t= he session timer.
Should UAs reject the UPDATE?

Regards,
Shinji

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000073390605a8a693e1-- From nobody Mon Jun 22 02:15:25 2020 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 E4E8B3A0BB6 for ; Mon, 22 Jun 2020 02:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQWePIaA0i1I for ; Mon, 22 Jun 2020 02:15:22 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 8A4203A0BB0 for ; Mon, 22 Jun 2020 02:15:22 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id s14so3230700plq.6 for ; Mon, 22 Jun 2020 02:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TKKgg6ltAgY66Zi9uUeauNs8FF/TDMVwF5EjC36TxKg=; b=b4u2O1OFMF1M8jiE7bF/RddvmzhHHUxdQJoFhTP4WnrjnDGIsT87fjMjUNDt3413UM k+MD7UBTKCXRRMvYpaC11XfcMJxGcuQZNO7ITIXxdBS6RsHHjYUAeOnoXtyjXeaVTXaW s8vqw+vF8/lYalTwA8rS6KCNLBbEs6Me7VGJVDt9t11S3zOrjir49Fb+mQwdu6GNtkZ5 y1tWEwA3o0fgxPonqJgu4SxNZkO1iLNPN3/RkxshfKN3CnPYcp8W+xgtcNxmdwhLOelI wODtJ2LVItlQM44VqLRM49HnFsEAFPJ19lmcqGF+qg5kyT6WpgSeq1S6gLQ0gN1+Si1L 9trg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TKKgg6ltAgY66Zi9uUeauNs8FF/TDMVwF5EjC36TxKg=; b=dXTQOyeFNoiU2MnLZCIadCIwuPxUnOPTFtSc6QS2VILCkjWpK2654OTWNdRCCi+cPP m6xTZpez7Ai5SFiuqywKAJSHCNPYo/fUKMTDpgJAyd0k+d7v8sqfbcRx5phvttRWthBR roce5Z9HmOZfpkb4AIs2d+gnp0b47lo78mVnZLvWVf6v5b2cNQBlf5T+3vF1cL+0scE7 XYbErf+LmPPL4c2UzM6QDcOK1oVL3hRszPBSe4aqu9xru0J+0u3odLyuMNLHrERF822c 9Iw1RbbZTCaX90ehu3TH8ydt3m3opDPeat+6ZnFg5O7CVx0xeioVNCHhwicxY4YiFjCT 5g1g== X-Gm-Message-State: AOAM532PSlmWwFbTELKxWFGbeA6hdznTcX7bywbC6MOHuYd96Ip3Ko7Z Si7vkJU1JgJn+za9gQ9PWn7Gm2il X-Google-Smtp-Source: ABdhPJzUpmFDJdu2lYOB7JThG6WCIzOSXiwsD73+VsDvA9hM+lHAFXXDOUuKVHqgih5Fo3ZvFj4fIA== X-Received: by 2002:a17:90a:d485:: with SMTP id s5mr16366406pju.61.1592817321931; Mon, 22 Jun 2020 02:15:21 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id d6sm13573593pjh.5.2020.06.22.02.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 02:15:21 -0700 (PDT) To: SIPCORE Cc: Roman Shpount References: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> From: OKUMURA Shinji Message-ID: <598ca935-49af-3acc-a97c-066b812ed381@gmail.com> Date: Mon, 22 Jun 2020 18:15:19 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 09:15:24 -0000 Roman, I thought you were in favor of the draft proposal, but were you against it? And if both session refresh requests are rejected with 491, will the proxy be negatively affected? Regards, Shinji On 2020/06/22 15:44, Roman Shpount wrote: > This is broken and not the solution for the session timer collision problem. > > Session-Expires is inserted by proxies. Proxies cannot reliably determine that another transaction is in progress. UA refusing session expires if another transaction is in progress will break existing implementations. > _____________ > Roman Shpount > > > On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji > wrote: > > Christer, > > Will you apply the following solutions to bis? > > draft-ietf-sipcore-sessiontimer-race-02 > 1.2.  Solution > >     This document updates [RFC4028], by clarifying the procedures for >     negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] >     session timer mechanism [RFC4028].  The following clarifications are >     provided: > >     o  A Session-Expires header field can only be included in a session >        refresh request if there is no ongoing negotiation of usage of the >        session timer mechanism, and if there is no ongoing INVITE >        transaction. >     o  A user agent shall, if it receives a session refresh request with a >        Session-Expires header field during an ongoing negotiation of >        usage of the session timer mechanism, or when there is an ongoing >        INVITE transaction, send a 491 (Request Pending) response to the >        request. >     o  The absence of a Session-Expires header field in a response will >        disable usage of the session timer mechanism only if the >        associated request contained a Session-Expires header field. > > Assuming all entities(UAC, UAS and proxies) keep a consistent policy for their own session-timer, even if transactions conflict, I think the results are also consistent. > Does the request still need to be reject with 491 in spite of no glare? > And an UPDATE request is used for updating a remote-target-uri as well as the session timer. > Should UAs reject the UPDATE? > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 22 02:21:16 2020 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 75DB43A0BC2 for ; Mon, 22 Jun 2020 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U97JqwWGAO5c for ; Mon, 22 Jun 2020 02:21:12 -0700 (PDT) Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 83AB33A0BC1 for ; Mon, 22 Jun 2020 02:21:12 -0700 (PDT) Received: by mail-oo1-xc34.google.com with SMTP id z127so749696ooa.3 for ; Mon, 22 Jun 2020 02:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8eU05/zEaUOZlnkrowWKn81gtK06y8HLlRoMJ/eMRC0=; b=P8ACJofpT4W1W1Wp3mxR4K34zMNLL6B31PC/FX63GO5QO6qfXrRWwkxiqTr6WPeFRD VBTLv6w3+OgZDx0BnP2Hzjy1tGPvbi+3f4xDgywQWg8zt8VWVkt4wowtZ1YAtCPwIDEj t0Sp7uFZHdSO/LcBd3UVaF2iQkh6QKip+HkkcDmXPVglGtGtKmbdE4Tjb+bdTQvJ9L4G BazCo/0v6yA2hE9szpkgnqf+LhZ4Y/G1HtdWTybhIMaJ70IrDZOZBzenf5yp4H6rdXPU PYaaSzHMwTrUF1l+njkM4HwFxD4tRg427vAsTfbdiO6oCR1bnyxS8K/8ZlvpnVlnAiZ3 b3Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8eU05/zEaUOZlnkrowWKn81gtK06y8HLlRoMJ/eMRC0=; b=JylodECd8x7GBZw8kqmkIBiPd7YjAogOWCkaqq7GwOwBrf3cZTenxU5AbeFnGPxQLo xMed4xtiiOj2DRXIayvBAGIs5iQwlJKS6w/85VDhrsnabSSxkmAqB7cP/6dOaQZhGKOm kbyfev6JerOMtk0mAqZDfTvpPDtQcXmxVUmZUe/PaoyyJpAqm5yKgtOA3hDLGowat3eY sJ6DO2N8/yy4yUai/mhu9gtnEAXXJhw2nTUHirZNh0jrhUCL+F479PVht+VNtbj97/BU 1QexRfhUCd6k6KZA0alxlwmKY4v7ZIcT1NPaAGc6SBuD9nEKBo5jpIXKfkrR4viVrLnZ F36g== X-Gm-Message-State: AOAM532jPYmFGNtKsV6HMVb8CeTBjqE3kGwL3Ag3zV/414no+weS4t9e hkoDnNxPux1CH6FaLCa8MZO7oXrf9ds= X-Google-Smtp-Source: ABdhPJz0NaJEOBY8sAR32AuROMc8AoxA7OhQ+kb5DychKbGBe6yZlhqKsGx/dTAEwMmYV+Z0VLZwUA== X-Received: by 2002:a4a:a10e:: with SMTP id i14mr13296744ool.68.1592817671303; Mon, 22 Jun 2020 02:21:11 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com. [209.85.210.54]) by smtp.gmail.com with ESMTPSA id q128sm3123004oig.25.2020.06.22.02.21.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 02:21:10 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id t6so12474667otk.9 for ; Mon, 22 Jun 2020 02:21:10 -0700 (PDT) X-Received: by 2002:a9d:604e:: with SMTP id v14mr13329672otj.39.1592817670040; Mon, 22 Jun 2020 02:21:10 -0700 (PDT) MIME-Version: 1.0 References: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> <598ca935-49af-3acc-a97c-066b812ed381@gmail.com> In-Reply-To: <598ca935-49af-3acc-a97c-066b812ed381@gmail.com> From: Roman Shpount Date: Mon, 22 Jun 2020 05:20:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000006a347005a8a8c3e5" Archived-At: Subject: Re: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 09:21:15 -0000 --0000000000006a347005a8a8c3e5 Content-Type: text/plain; charset="UTF-8" Shinji, This draft was severely out of date. Proposals in it have known problems. _____________ Roman Shpount On Mon, Jun 22, 2020 at 5:15 AM OKUMURA Shinji wrote: > Roman, > > I thought you were in favor of the draft proposal, but were you against it? > And if both session refresh requests are rejected with 491, will the proxy > be negatively affected? > > Regards, > Shinji > > On 2020/06/22 15:44, Roman Shpount wrote: > > This is broken and not the solution for the session timer > collision problem. > > > > Session-Expires is inserted by proxies. Proxies cannot reliably > determine that another transaction is in progress. UA refusing session > expires if another transaction is in progress will break existing > implementations. > > _____________ > > Roman Shpount > > > > > > On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji > wrote: > > > > Christer, > > > > Will you apply the following solutions to bis? > > > > draft-ietf-sipcore-sessiontimer-race-02 > > 1.2. Solution > > > > This document updates [RFC4028], by clarifying the procedures > for > > negotiating usage of the Session Initiation Protocol (SIP) > [RFC3261] > > session timer mechanism [RFC4028]. The following > clarifications are > > provided: > > > > o A Session-Expires header field can only be included in a > session > > refresh request if there is no ongoing negotiation of usage > of the > > session timer mechanism, and if there is no ongoing INVITE > > transaction. > > o A user agent shall, if it receives a session refresh request > with a > > Session-Expires header field during an ongoing negotiation of > > usage of the session timer mechanism, or when there is an > ongoing > > INVITE transaction, send a 491 (Request Pending) response to > the > > request. > > o The absence of a Session-Expires header field in a response > will > > disable usage of the session timer mechanism only if the > > associated request contained a Session-Expires header field. > > > > Assuming all entities(UAC, UAS and proxies) keep a consistent policy > for their own session-timer, even if transactions conflict, I think the > results are also consistent. > > Does the request still need to be reject with 491 in spite of no > glare? > > And an UPDATE request is used for updating a remote-target-uri as > well as the session timer. > > Should UAs reject the UPDATE? > > > > Regards, > > Shinji > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --0000000000006a347005a8a8c3e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

This draft was severely out of date. Proposals in it have known pr= oblems.
_____________
Roman Shpount
=

On Mon, Jun 22, 2020 at 5:15 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
Roman,

I thought you were in favor of the draft proposal, but were you against it?=
And if both session refresh requests are rejected with 491, will the proxy = be negatively affected?

Regards,
Shinji

On 2020/06/22 15:44, Roman Shpount wrote:
> This is broken=C2=A0and not the solution for the session timer collisi= on=C2=A0problem.
>
> Session-Expires is inserted by proxies. Proxies cannot reliably determ= ine that another transaction is in progress. UA refusing session expires if= another transaction is in progress will break existing implementations. > _____________
> Roman Shpount
>
>
> On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji <ietf.shinji@gmail.com <mailt= o:ietf.shinji@gm= ail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Christer,
>
>=C2=A0 =C2=A0 =C2=A0Will you apply the following solutions to bis?
>
>=C2=A0 =C2=A0 =C2=A0draft-ietf-sipcore-sessiontimer-race-02
>=C2=A0 =C2=A0 =C2=A01.2.=C2=A0 Solution
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document updates [RFC4028], by = clarifying the procedures for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 negotiating usage of the Session Ini= tiation Protocol (SIP) [RFC3261]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 session timer mechanism [RFC4028].= =C2=A0 The following clarifications are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 provided:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 A Session-Expires header fie= ld can only be included in a session
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0refresh request if ther= e is no ongoing negotiation of usage of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session timer mechanism= , and if there is no ongoing INVITE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transaction.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 A user agent shall, if it re= ceives a session refresh request with a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session-Expires header = field during an ongoing negotiation of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0usage of the session ti= mer mechanism, or when there is an ongoing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INVITE transaction, sen= d a 491 (Request Pending) response to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 The absence of a Session-Exp= ires header field in a response will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0disable usage of the se= ssion timer mechanism only if the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated request cont= ained a Session-Expires header field.
>
>=C2=A0 =C2=A0 =C2=A0Assuming all entities(UAC, UAS and proxies) keep a = consistent policy for their own session-timer, even if transactions conflic= t, I think the results are also consistent.
>=C2=A0 =C2=A0 =C2=A0Does the request still need to be reject with 491 i= n spite of no glare?
>=C2=A0 =C2=A0 =C2=A0And an UPDATE request is used for updating a remote= -target-uri as well as the session timer.
>=C2=A0 =C2=A0 =C2=A0Should UAs reject the UPDATE?
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Shinji
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>
--0000000000006a347005a8a8c3e5-- From nobody Mon Jun 22 02:29:28 2020 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 2E7C93A0BCF for ; Mon, 22 Jun 2020 02:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fw1XPGlMLPY for ; Mon, 22 Jun 2020 02:29:24 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 A37583A0BA9 for ; Mon, 22 Jun 2020 02:29:24 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id b7so6464662pju.0 for ; Mon, 22 Jun 2020 02:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=apyZlrjzTcLN/xE1E8x3HQnNOyHfRKkxp8TTgusbMB0=; b=Dy8i++4HbhKDks0qblcYX7ctmQUw8oNmfsCyjBDLUnUL1V0kZ1ADTvK33gVedVqdi6 RbrSFKq0tdowIg7NNNyuJAk5YtsSe9/aYrF9jsG/CkPvX5pM1yGmybbhtuLikdYMsPx4 lWdMAkV8jF/27Qk1iDvz61QrxPpvKEpDC4SBp4FU0WiLy+AG3uBCRDc+MoZ2uL16z0TV 3lva1DOzVT2iz5+Avvno7VInwsSWQHjRgI1RgxexAyIG13WHJ8JtsIadJ8cNO94zJRTw 6SCC/dygIV6I29f1at3sGzDJchN9Scs4j7kb+ZMoYrwQn61TKuKtPG0aGpD+3fXy10wd 38+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=apyZlrjzTcLN/xE1E8x3HQnNOyHfRKkxp8TTgusbMB0=; b=kfzdKMn3XzdZXc1GjHaEDJAwbUsfKeRwnN8mPNOGCY8Bfu67H+ZfQnE3HrvueUs3hA NmnpsEtNIMybc/oAjYXK1II0D43Uwj8PQBeNGLIdSkTJHmVoETnTKafwV5IMuYTshfk7 rEMg+IF4/zr+ue/S9frMyeTi7uSYjtFJ4mkQRY8/hk1x8bgQ8p/XOEcTN+RvXpBF3oOq rz30bc6ehrvlEzo6+PdjT9N2wfaidbjrVlqhUtPx0gp0QEJoUtGqXQTUKbF7oEmeN8Xa XnE6BVec1s3Pcl+8u7gyOe8RrsrNr9T3Qb5lLA4z2GOeXAc9Z7c7J5EyxVyw3XRsQnkg 9/Pg== X-Gm-Message-State: AOAM532imU7DTV+3dpa9G+5TApF83PKcUO3SOjGkhGKSecu34xvW7vGg 0RhOYJNXyv4z9X1CvO0cSd4= X-Google-Smtp-Source: ABdhPJx8r1lFafp9EUz0XPNvnKeW5FIcwywLLrA8zMxf0oolOU1dyBXM2uo104peR7GTt0AKtHfvgg== X-Received: by 2002:a17:90a:6ace:: with SMTP id b14mr17556544pjm.13.1592818164107; Mon, 22 Jun 2020 02:29:24 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id fy21sm12643153pjb.38.2020.06.22.02.29.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 02:29:23 -0700 (PDT) To: Roman Shpount Cc: SIPCORE , Christer Holmberg References: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> <598ca935-49af-3acc-a97c-066b812ed381@gmail.com> From: OKUMURA Shinji Message-ID: <749a482a-8d9b-93e6-33f2-264ed05fcb68@gmail.com> Date: Mon, 22 Jun 2020 18:29:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 09:29:26 -0000 Hi, The race condition resolution should be in the main scope, but where is the latest proposal for this part? Regards, Shinji On 2020/06/22 18:20, Roman Shpount wrote: > Shinji, > > This draft was severely out of date. Proposals in it have known problems. > _____________ > Roman Shpount > > > On Mon, Jun 22, 2020 at 5:15 AM OKUMURA Shinji > wrote: > > Roman, > > I thought you were in favor of the draft proposal, but were you against it? > And if both session refresh requests are rejected with 491, will the proxy be negatively affected? > > Regards, > Shinji > > On 2020/06/22 15:44, Roman Shpount wrote: > > This is broken and not the solution for the session timer collision problem. > > > > Session-Expires is inserted by proxies. Proxies cannot reliably determine that another transaction is in progress. UA refusing session expires if another transaction is in progress will break existing implementations. > > _____________ > > Roman Shpount > > > > > > On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji >> wrote: > > > >     Christer, > > > >     Will you apply the following solutions to bis? > > > >     draft-ietf-sipcore-sessiontimer-race-02 > >     1.2.  Solution > > > >          This document updates [RFC4028], by clarifying the procedures for > >          negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] > >          session timer mechanism [RFC4028].  The following clarifications are > >          provided: > > > >          o  A Session-Expires header field can only be included in a session > >             refresh request if there is no ongoing negotiation of usage of the > >             session timer mechanism, and if there is no ongoing INVITE > >             transaction. > >          o  A user agent shall, if it receives a session refresh request with a > >             Session-Expires header field during an ongoing negotiation of > >             usage of the session timer mechanism, or when there is an ongoing > >             INVITE transaction, send a 491 (Request Pending) response to the > >             request. > >          o  The absence of a Session-Expires header field in a response will > >             disable usage of the session timer mechanism only if the > >             associated request contained a Session-Expires header field. > > > >     Assuming all entities(UAC, UAS and proxies) keep a consistent policy for their own session-timer, even if transactions conflict, I think the results are also consistent. > >     Does the request still need to be reject with 491 in spite of no glare? > >     And an UPDATE request is used for updating a remote-target-uri as well as the session timer. > >     Should UAs reject the UPDATE? > > > >     Regards, > >     Shinji > > > >     _______________________________________________ > >     sipcore mailing list > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Mon Jun 22 02:34:35 2020 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 A1B633A0BD4 for ; Mon, 22 Jun 2020 02:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8zgOTLIvjMvN for ; Mon, 22 Jun 2020 02:34:32 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150052.outbound.protection.outlook.com [40.107.15.52]) (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 735093A0BCC for ; Mon, 22 Jun 2020 02:34:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQNpMK81pRlpmcwudA7M8/9BMNScsjrJWjLeCDoBVmyGL3SuUaKcb4SQO0b73WO11jbUPSdOGwTxI/o1MQ1A8un5nCqPjQ7GA2kXNHSvdG58CMiDIe6Ww+ry5sq6ABu94lzIukMK3dQD7mRfWgK3pS0SeJtUmiVGREnjYHGCHVG2avvDNGGzAkIihrTU2qBvRFnBuwV83mdzoBFmQu8hWnUuhvU7vNMaMf484AuQ6pg6DYxqMODMFpvtOtPFUtVfqfqWf8U2hzhfB+C9GRnvy5J68EfPZ3kYFHd0S3/A5ssi2o1crl+zi7JfDWDCf/2ozhVcv0Zd9thA7GEDuDW6fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bQjW+w87qIZ7j75OVRQFhfzS7iNDWO910VzDHNDJ0dE=; b=acKC3yoo27rFgeyfWB85GyF+SLyiYC1ie3XT8VUIkGFQlsH5Zf9uo0GGIs2zaeaDCyPqEn0a7lUcsmvLMs1pU6vI5sQk3b/Ns77f/VCwECj4aYE51IpxUk8OJ2w+eFG8k5bK9gtAOMTfBXH5nMubcgJCyhDOcGNDzQ8bP4IF3jFbnv4T1ipjteaOpiJaaemujRY2Iong27o9W5OYWRMAdq4hNHW7VkZtR0c3Gsz+3NGyOdTDZxugq1+ufsQ2pz21YyceBuW9kjeApd15O+A+CMCogQwk1ZxAdVWWx0u6MMNrllLAACiC4/ZOODYueqw0KLfEoPLQOEf284LyQaQZeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bQjW+w87qIZ7j75OVRQFhfzS7iNDWO910VzDHNDJ0dE=; b=q5Mi8cJ2uhaFp1EK1s3VNQPOjaL4Vu3yam7rsGVfSEnEMzwku6DZPfo1zxsPpv0NDrpkbx+jEYDwNrS4gmmqo3XisYsuCy9wpcsK6niBY5CC1yH7GhlcaNuFW+hOu5Oww6nKqJKKsXx5shNPAXGJYuigmSIKPFNuHMU4Ttrm9Xw= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM6PR07MB6039.eurprd07.prod.outlook.com (2603:10a6:20b:9e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.13; Mon, 22 Jun 2020 09:34:25 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3131.009; Mon, 22 Jun 2020 09:34:25 +0000 From: Christer Holmberg To: OKUMURA Shinji , Roman Shpount CC: SIPCORE Thread-Topic: [sipcore] RFC4028 : sessiontimer-race Thread-Index: AQHWRVWU6PHS06eTRU+0xnirDoeKUqjkNnYAgAAqK4CAAAGUAIAAAleAgAABH3A= Date: Mon, 22 Jun 2020 09:34:25 +0000 Message-ID: References: <7c016eca-e3a1-e2af-cf70-6757f782eaf8@gmail.com> <598ca935-49af-3acc-a97c-066b812ed381@gmail.com> <749a482a-8d9b-93e6-33f2-264ed05fcb68@gmail.com> In-Reply-To: <749a482a-8d9b-93e6-33f2-264ed05fcb68@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed5ef31d-75cb-4a99-2d46-08d8168f7428 x-ms-traffictypediagnostic: AM6PR07MB6039: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lVWF8SBev2CFnwB0YCdKNCNlyIlpUmjHcUSDZQgL4jDYV4rS6i1CBRrZUqirqY254kiQa4oDTw7ckm48qMf7wOppyCTzgm7UixwZVjmqQjEyef4InRv3n24oD9HUfa2egIHB1kT3ksAnwJD9F8HkKBfFTR7/15oMZ8KzaR+lVBdYyX1PG4vAAgA+9xdGfpSv0vE+fIvGUx6wqA33PQFQl3yhTyXhNrUZWZ6Budm6EJu7xcA/jSU8QfgrTaE5gMbNKXcOX5bEFr5QFJ5vPU5sHorN3NZ46U4FzI1hoTN3t8jWTSKYaZjbqviVyxT1LFEQStLuKE7ziZX6XsU3MGWfZiK0EgJErVtwHB6+ynbphBjYZUZ+HPL530fxg0XRE9YUK4LacY3hDrpkVf2gxTbUeg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(136003)(39860400002)(396003)(53546011)(8676002)(4326008)(2906002)(71200400001)(9686003)(110136005)(55016002)(7696005)(83380400001)(86362001)(8936002)(478600001)(966005)(316002)(26005)(186003)(6506007)(66574015)(33656002)(66946007)(66476007)(76116006)(66556008)(44832011)(52536014)(66446008)(5660300002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CBRgFE9yrsyfrhvix4Cx4Bu+j0HoMsyS48DMLGn/hzJ7+bo/MYbjfFplKAxiDN1yGr6ZrBCWml3m2y5rLPA9RDtui02yZAJz0tZlKurzfUqAlG8ulSCMzOhKPIAeOgslN3LCOSzIzjbR9BsUt7az9FWHiMqxLh/1MZRVGnjIwLIGW85WhlrMAzE7OLZZaRGRcVX191NFiLyGrdqVED/72zQTEx8d0lBiZKB3ceTkoYfbb5oq6R1d1oTSHIcYetwscDHJeUwQ1jkNTmEwScjdj0HDpXtlMs6kcR1RpExZgw/UpTsE28BoEN16WhsWg/JGZ6Wf4jGf+i2GAGoO1TL5laPLksojcW3D8mXWiwKLEYGYPNRqqlwrRVPhl1m2uAL/qc2vAtTIA1EVKKy6SZAV5AFLVCzkfI/ZPRWTVQtLWWyvbmSjLJP/xusbDrxk1L2jRUDC83qzyAsRM1UkzZuEXzXyayGI6MdTmIABsdqnpsNKH1vFbAkHSUpZmObBPXHk x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB7012.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed5ef31d-75cb-4a99-2d46-08d8168f7428 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 09:34:25.6764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DN9WIA+ECJpu7qQwfJyv99hBbz75WE990vD1jBtQI/Mu1GvcfIz+MR+bLogzGJkA9qjd2iMpg4TbQz/UlLHX/Fxo7IwWMGkxbuf3Q0SXKNE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6039 Archived-At: Subject: Re: [sipcore] RFC4028 : sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 09:34:35 -0000 SGksDQoNClRoZXJlIGlzIG5vIHRleHQgcHJvcG9zYWwgeWV0LiBXZSBoYXZlIGEgaGlnaC1sZXZl bCBhZ3JlZW1lbnQgb24gaG93IHRvIHNvbHZlIHRoZSBpc3N1ZSwgYW5kIHRoZSBwbGFuIGlzIHRv IGdlbmVyYXRlIHRleHQgYmFzZWQgb24gdGhhdC4NCg0KTm90ZSB0aGF0IHRoZSBjdXJyZW50IHZl cnNpb24gb2YgdGhlIGJpcyBkcmFmdCBpcyBhIGNvcHkgb2YgdGhlIFJGQy4gTm8gY2hhbmdlcyBo YXZlIGJlZW4gaW1wbGVtZW50ZWQgeWV0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0tVTVVSQSBTaGluamkgPGlldGYuc2hpbmpp QGdtYWlsLmNvbT4gDQpTZW50OiBtYWFuYW50YWkgMjIuIGtlc8Oka3V1dGEgMjAyMCAxMi4yOQ0K VG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KQ2M6IFNJUENPUkUgPHNpcGNv cmVAaWV0Zi5vcmc+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRkM0MDI4IDogc2Vzc2lvbnRpbWVyLXJh Y2UNCg0KSGksDQoNClRoZSByYWNlIGNvbmRpdGlvbiByZXNvbHV0aW9uIHNob3VsZCBiZSBpbiB0 aGUgbWFpbiBzY29wZSwgYnV0IHdoZXJlIGlzIHRoZSBsYXRlc3QgcHJvcG9zYWwgZm9yIHRoaXMg cGFydD8NCg0KUmVnYXJkcywNClNoaW5qaQ0KDQpPbiAyMDIwLzA2LzIyIDE4OjIwLCBSb21hbiBT aHBvdW50IHdyb3RlOg0KPiBTaGluamksDQo+IA0KPiBUaGlzIGRyYWZ0IHdhcyBzZXZlcmVseSBv dXQgb2YgZGF0ZS4gUHJvcG9zYWxzIGluIGl0IGhhdmUga25vd24gcHJvYmxlbXMuDQo+IF9fX19f X19fX19fX18NCj4gUm9tYW4gU2hwb3VudA0KPiANCj4gDQo+IE9uIE1vbiwgSnVuIDIyLCAyMDIw IGF0IDU6MTUgQU0gT0tVTVVSQSBTaGluamkgPGlldGYuc2hpbmppQGdtYWlsLmNvbSA8bWFpbHRv OmlldGYuc2hpbmppQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiANCj4gICAgIFJvbWFuLA0KPiANCj4g ICAgIEkgdGhvdWdodCB5b3Ugd2VyZSBpbiBmYXZvciBvZiB0aGUgZHJhZnQgcHJvcG9zYWwsIGJ1 dCB3ZXJlIHlvdSBhZ2FpbnN0IGl0Pw0KPiAgICAgQW5kIGlmIGJvdGggc2Vzc2lvbiByZWZyZXNo IHJlcXVlc3RzIGFyZSByZWplY3RlZCB3aXRoIDQ5MSwgd2lsbCB0aGUgcHJveHkgYmUgbmVnYXRp dmVseSBhZmZlY3RlZD8NCj4gDQo+ICAgICBSZWdhcmRzLA0KPiAgICAgU2hpbmppDQo+IA0KPiAg ICAgT24gMjAyMC8wNi8yMiAxNTo0NCwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4gICAgICA+IFRo aXMgaXMgYnJva2VuwqBhbmQgbm90IHRoZSBzb2x1dGlvbiBmb3IgdGhlIHNlc3Npb24gdGltZXIg Y29sbGlzaW9uwqBwcm9ibGVtLg0KPiAgICAgID4NCj4gICAgICA+IFNlc3Npb24tRXhwaXJlcyBp cyBpbnNlcnRlZCBieSBwcm94aWVzLiBQcm94aWVzIGNhbm5vdCByZWxpYWJseSBkZXRlcm1pbmUg dGhhdCBhbm90aGVyIHRyYW5zYWN0aW9uIGlzIGluIHByb2dyZXNzLiBVQSByZWZ1c2luZyBzZXNz aW9uIGV4cGlyZXMgaWYgYW5vdGhlciB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcyB3aWxsIGJy ZWFrIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4NCj4gICAgICA+IF9fX19fX19fX19fX18NCj4g ICAgICA+IFJvbWFuIFNocG91bnQNCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4gT24gVGh1 LCBKdW4gMTgsIDIwMjAgYXQgNTo0OCBBTSBPS1VNVVJBIFNoaW5qaSA8aWV0Zi5zaGluamlAZ21h aWwuY29tIDxtYWlsdG86aWV0Zi5zaGluamlAZ21haWwuY29tPiA8bWFpbHRvOmlldGYuc2hpbmpp QGdtYWlsLmNvbSA8bWFpbHRvOmlldGYuc2hpbmppQGdtYWlsLmNvbT4+PiB3cm90ZToNCj4gICAg ICA+DQo+ICAgICAgPsKgIMKgIMKgQ2hyaXN0ZXIsDQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDC oFdpbGwgeW91IGFwcGx5IHRoZSBmb2xsb3dpbmcgc29sdXRpb25zIHRvIGJpcz8NCj4gICAgICA+ DQo+ICAgICAgPsKgIMKgIMKgZHJhZnQtaWV0Zi1zaXBjb3JlLXNlc3Npb250aW1lci1yYWNlLTAy DQo+ICAgICAgPsKgIMKgIMKgMS4yLsKgIFNvbHV0aW9uDQo+ICAgICAgPg0KPiAgICAgID7CoCDC oCDCoCDCoCDCoCBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgW1JGQzQwMjhdLCBieSBjbGFyaWZ5aW5n IHRoZSBwcm9jZWR1cmVzIGZvcg0KPiAgICAgID7CoCDCoCDCoCDCoCDCoCBuZWdvdGlhdGluZyB1 c2FnZSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXQ0K PiAgICAgID7CoCDCoCDCoCDCoCDCoCBzZXNzaW9uIHRpbWVyIG1lY2hhbmlzbSBbUkZDNDAyOF0u wqAgVGhlIGZvbGxvd2luZyBjbGFyaWZpY2F0aW9ucyBhcmUNCj4gICAgICA+wqAgwqAgwqAgwqAg wqAgcHJvdmlkZWQ6DQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoCDCoCDCoCBvwqAgQSBTZXNz aW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkIGNhbiBvbmx5IGJlIGluY2x1ZGVkIGluIGEgc2Vzc2lv bg0KPiAgICAgID7CoCDCoCDCoCDCoCDCoCDCoCDCoHJlZnJlc2ggcmVxdWVzdCBpZiB0aGVyZSBp cyBubyBvbmdvaW5nIG5lZ290aWF0aW9uIG9mIHVzYWdlIG9mIHRoZQ0KPiAgICAgID7CoCDCoCDC oCDCoCDCoCDCoCDCoHNlc3Npb24gdGltZXIgbWVjaGFuaXNtLCBhbmQgaWYgdGhlcmUgaXMgbm8g b25nb2luZyBJTlZJVEUNCj4gICAgICA+wqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFuc2FjdGlvbi4N Cj4gICAgICA+wqAgwqAgwqAgwqAgwqAgb8KgIEEgdXNlciBhZ2VudCBzaGFsbCwgaWYgaXQgcmVj ZWl2ZXMgYSBzZXNzaW9uIHJlZnJlc2ggcmVxdWVzdCB3aXRoIGENCj4gICAgICA+wqAgwqAgwqAg wqAgwqAgwqAgwqBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkIGR1cmluZyBhbiBvbmdvaW5n IG5lZ290aWF0aW9uIG9mDQo+ICAgICAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgdXNhZ2Ugb2YgdGhl IHNlc3Npb24gdGltZXIgbWVjaGFuaXNtLCBvciB3aGVuIHRoZXJlIGlzIGFuIG9uZ29pbmcNCj4g ICAgICA+wqAgwqAgwqAgwqAgwqAgwqAgwqBJTlZJVEUgdHJhbnNhY3Rpb24sIHNlbmQgYSA0OTEg KFJlcXVlc3QgUGVuZGluZykgcmVzcG9uc2UgdG8gdGhlDQo+ICAgICAgPsKgIMKgIMKgIMKgIMKg IMKgIMKgcmVxdWVzdC4NCj4gICAgICA+wqAgwqAgwqAgwqAgwqAgb8KgIFRoZSBhYnNlbmNlIG9m IGEgU2Vzc2lvbi1FeHBpcmVzIGhlYWRlciBmaWVsZCBpbiBhIHJlc3BvbnNlIHdpbGwNCj4gICAg ICA+wqAgwqAgwqAgwqAgwqAgwqAgwqBkaXNhYmxlIHVzYWdlIG9mIHRoZSBzZXNzaW9uIHRpbWVy IG1lY2hhbmlzbSBvbmx5IGlmIHRoZQ0KPiAgICAgID7CoCDCoCDCoCDCoCDCoCDCoCDCoGFzc29j aWF0ZWQgcmVxdWVzdCBjb250YWluZWQgYSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkLg0K PiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBBc3N1bWluZyBhbGwgZW50aXRpZXMoVUFDLCBVQVMg YW5kIHByb3hpZXMpIGtlZXAgYSBjb25zaXN0ZW50IHBvbGljeSBmb3IgdGhlaXIgb3duIHNlc3Np b24tdGltZXIsIGV2ZW4gaWYgdHJhbnNhY3Rpb25zIGNvbmZsaWN0LCBJIHRoaW5rIHRoZSByZXN1 bHRzIGFyZSBhbHNvIGNvbnNpc3RlbnQuDQo+ICAgICAgPsKgIMKgIMKgRG9lcyB0aGUgcmVxdWVz dCBzdGlsbCBuZWVkIHRvIGJlIHJlamVjdCB3aXRoIDQ5MSBpbiBzcGl0ZSBvZiBubyBnbGFyZT8N Cj4gICAgICA+wqAgwqAgwqBBbmQgYW4gVVBEQVRFIHJlcXVlc3QgaXMgdXNlZCBmb3IgdXBkYXRp bmcgYSByZW1vdGUtdGFyZ2V0LXVyaSBhcyB3ZWxsIGFzIHRoZSBzZXNzaW9uIHRpbWVyLg0KPiAg ICAgID7CoCDCoCDCoFNob3VsZCBVQXMgcmVqZWN0IHRoZSBVUERBVEU/DQo+ICAgICAgPg0KPiAg ICAgID7CoCDCoCDCoFJlZ2FyZHMsDQo+ICAgICAgPsKgIMKgIMKgU2hpbmppDQo+ICAgICAgPg0K PiAgICAgID7CoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ICAgICAgPsKgIMKgIMKgc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gICAgICA+IHNp cGNvcmVAaWV0Zi5vcmcgPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPiA8bWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmcgPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPj4NCj4gICAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiAgICAgID4NCj4gDQo= From nobody Tue Jun 23 14:17:26 2020 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 045833A0B77 for ; Tue, 23 Jun 2020 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 JUCEVQfaayoU for ; Tue, 23 Jun 2020 14:17:23 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 7E8D03A0B30 for ; Tue, 23 Jun 2020 14:17:23 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id k4so20102196oik.2 for ; Tue, 23 Jun 2020 14:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=36aPcLHthOoW5GoAgp4mpt8zMRca0JNW4qoj7w7upJM=; b=y1vXFYvE9BqXKqnKMrp0r/tYVSiBRPRL5jHXFFpKV3pR1tXtjr+ACFvbSe3U0Un86C XQul8NreY+5dCf0WqgCXzTZD2cBoQ+vAxdGdttUrsNEdDAf4XWe3aPqgwLkcuLlbzUgD 1uGpmdj9oLueWAZvvQ9xvCFBYkqolKG8LnZ+kFznE24omwIxDypfqQyr9ArvJRLYMpMr VeiBr4/PNk2tWxF0wFRYNmgA9ZisQpj+hZYQDc6alTl7Zc5Y9/Ncs/R/xWUgNjX6yqEl FyJZ8kUt+LW6+wGPOuFhic9PJVuKCdOkxyT8Jq2eL1UFO2PpATI8MMaumt6kq7c3BVdE d2hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=36aPcLHthOoW5GoAgp4mpt8zMRca0JNW4qoj7w7upJM=; b=YkbjQzXdkw1kwRWxt3sGy6qdQWvT7EadRhCHrEfulwmE8awlmtzN3iUzFgyZOYXqbL RH85l8pjNLLewTucOemSTlNURKdZxJJiALDIUnIDZa/Nq0s+MaHUqcbW3tWuLbrCz3CU dm+BHD8YZgDyZT9R21h2bTrr9B82fL3i83sbmjdNma2ifqY6zm8SAIQHh1wov3EjSwaM FLY3ORE+UpfYQ9I9suWwcLSJD6P5wJ4tTM/WT9k7Wzyo+pJGxiQO6e00IqN7lZSRbTjP 6UmCzmpzVjSUk0QA0okWPp1zU0uL3VcPzBIeR0KQc4RofE0AB1m/NjjB5Kfbjs/acrh6 mCeQ== X-Gm-Message-State: AOAM533VpsrNogyZI+jLv1aj/XIMC8Xhj6o8scNGB/m1N0GXtvUWJHT2 5EU8cjEQKgRX43TC8ipBX0kHHvVnmr8= X-Google-Smtp-Source: ABdhPJyMQ1oRKuoDKamUSm11/y4O7XyH4Vm1sYXg3WOcPFIcURqT0rInuRFXe6soMi29KoMKBRQQ3g== X-Received: by 2002:aca:1217:: with SMTP id 23mr17188888ois.125.1592947042238; Tue, 23 Jun 2020 14:17:22 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com. [209.85.210.44]) by smtp.gmail.com with ESMTPSA id r7sm4483891oor.9.2020.06.23.14.17.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 14:17:21 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id 72so4617198otc.3 for ; Tue, 23 Jun 2020 14:17:20 -0700 (PDT) X-Received: by 2002:a9d:604e:: with SMTP id v14mr20371177otj.39.1592947040473; Tue, 23 Jun 2020 14:17:20 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> In-Reply-To: From: Roman Shpount Date: Tue, 23 Jun 2020 17:17:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , Paul Kyzivat Content-Type: multipart/alternative; boundary="0000000000007e589405a8c6e2e6" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 21:17:25 -0000 --0000000000007e589405a8c6e2e6 Content-Type: text/plain; charset="UTF-8" Hi Shinji, On Sat, Jun 13, 2020 at 5:05 AM OKUMURA Shinji wrote: > > 1. Handling of UPDATE with no SDP glare > > This issue should have been a main scope in the first place. And there > have been a lot of discussion about this kind of glare at the time of the > consideration of RFC 6141. > I think we can adapt the same solution. Rather, I've thought that this > text was proposing such a solution. > > I'm not going to deny the solution with the 491 response, but I think it > has a big impact. It seems strange to me that I would point this out. > The situation with session timers is different from target refresh. Target refresh is updated for each UA independently. Session timer is negotiated for the entire session, so more collision scenarios are possible. One of such scenarios is both UA sending UPDATE at the same time. If these UPDATE requests do not carry SDP, currently they should be accepted. Resulting session timer state is ambiguous. The only reliable way to prevent ambiguous session timer state in this case is to refuse the UPDATE message, similar to the session description collision. This is why 491 was suggested. > 2. Handling of UPDATE transactions during initial INVITE > > First of all, I have no doubt that a session-timer is started when a 2xx > response of an initial INVITE is received. In other words, a session-timer > is not activated during an early dialog. > > And the UPDATE order problem is one of original(RFC3311) SIP shortcomings. > RFC6141 says, if in doubt, send a refresh request to confirm. > This is exactly the reason why handling of UPDATE transaction collisions needs to be resolved. If session timer ends up in an ambiguous state, it is likely ambiguous for both UA and both UA will initiate an UPDATE refresh request to confirm, which will result in a collision. Best Regards, _____________ Roman Shpount --0000000000007e589405a8c6e2e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Shinji,

= On Sat, Jun 13, 2020 at 5:05 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
> 1. = Handling of UPDATE with no SDP glare

This issue should have been a main scope in the first place. And there have= been a lot of discussion about this kind of glare at the time of the consi= deration of RFC 6141.
I think we can adapt the same solution. Rather, I've thought that this = text was proposing such a solution.

I'm not going to deny the solution with the 491 response, but I think i= t has a big impact. It seems strange to me that I would point this out.
=

The situation with session timers is diffe= rent from target refresh. Target refresh is updated for each UA independent= ly. Session timer is negotiated for the entire=C2=A0session, so more collis= ion=C2=A0scenarios are possible. One of such scenarios is both UA sending U= PDATE at the same time. If these UPDATE=C2=A0requests do not carry SDP, cur= rently they should be accepted. Resulting session timer state is ambiguous.= The only reliable way to prevent ambiguous session timer state in this cas= e is to refuse the UPDATE message, similar to the session description colli= sion. This is why 491 was suggested.

> 2. Handling of UPDATE transactions du= ring initial INVITE

First of all, I have no doubt that a session-timer is started when a 2xx re= sponse of an initial INVITE is received. In other words, a session-timer is= not activated during an early dialog.

And the UPDATE order problem is one of original(RFC3311) SIP shortcomings.<= br> RFC6141 says, if in doubt, send a refresh request to confirm.

This is exactly the reason why handling of UPDATE tr= ansaction collisions needs to be resolved. If session timer ends up in an a= mbiguous=C2=A0state, it is likely=20 ambiguous for both UA and both UA will initiate an UPDATE refresh request t= o confirm, which will result in a collision.

Best = Regards,
_____________
Roman Shpount

=C2=A0
--0000000000007e589405a8c6e2e6-- From nobody Tue Jun 23 22:04:20 2020 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 C73F73A07EC for ; Tue, 23 Jun 2020 22:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX1tPr2nS_sf for ; Tue, 23 Jun 2020 22:04:16 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 AD5953A07EE for ; Tue, 23 Jun 2020 22:04:16 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id h185so595269pfg.2 for ; Tue, 23 Jun 2020 22:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EQHBR1wlAllMQm++idtCW+ddxBac3ydwkT23ZOJhUtg=; b=kluAt8w+riTtesMkRT8uSffzJ9h/auYO9InRFtEvfafoKhqGctlmfpoijQOhXNok9f szJZZGfwjyEAWukVeSqp6ETGoIxEIgE14D9VsvRM3KX242sANFMz3aJIgPUfFcl1FV1A 5l1ZTxJrB1WKl+8P9Fntz81DKEapMKN0DzYTBNIIHonHZTJ/JoOnqvZK2ExtvGJkl7YW tCpVC42xYAfo0elp937OMDiuXGrRd8/HSbMf9Znry96D7CGRHlEvINLoo7sbZzfnbakl 03pN4y5drG6lzPHf2/HCr+BXzfzGMhvWJr14RKsnu58iuWq088GcMDGADfVDZ63qCj5F 8q1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EQHBR1wlAllMQm++idtCW+ddxBac3ydwkT23ZOJhUtg=; b=Ye5F6+aAIs07Ec9kpASzPNajICvROIiDUWd27UGAeFWukBaPRCpTiYzetFlZlVgloq 2zRVluvxYrnBuQINhVJeTlHgiqTDiOtiv3yEzz8J5PHQzBlREI17UWRd8D7pPIYT17yZ j/soQqTv+AIGTXVNifepnmfHSqCk25En6ZOVXa/x+ugx3zClkqs3ipop+ddk+O0DcT7O Ce2iXmuVtnDUU8N/Y8SMnb0l3ScqRlRXhItCcfn0QFj8bpkcOUVB2yC86D9mZu/VTM9R 18rBR4b2nID9SplMbWYC+NZK0KOeNo+ASnXuI5n8LJKC/7I0Mr2NKAONX8wbj6f6/x/I Swjg== X-Gm-Message-State: AOAM531euDtomEmbkQwCbxbqYijXJUeh5NXtdRae3cy+ZOUiijVY7xAl p+BB+N+gHmvb4JS+TQqnVSQ= X-Google-Smtp-Source: ABdhPJxKlBRvS4DAg751OWUtG4Z0/YPeQuSp+QjBYQ9aQ3RSCwb/hWv/4j0+2Z1WvlvK7YzR0M9EHg== X-Received: by 2002:a62:2bc6:: with SMTP id r189mr27019447pfr.11.1592975055150; Tue, 23 Jun 2020 22:04:15 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id z85sm19181032pfc.66.2020.06.23.22.04.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 22:04:14 -0700 (PDT) To: Roman Shpount Cc: SIPCORE , Paul Kyzivat References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> From: OKUMURA Shinji Message-ID: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> Date: Wed, 24 Jun 2020 14:04:12 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:04:18 -0000 Roman, >> 1. Handling of UPDATE with no SDP glare >> I'm not going to deny the solution with the 491 response, but I think it has a big impact. > > The situation with session timers is different from target refresh. Target refresh is updated for each UA independently. Session timer is negotiated for the entire session, so more collision scenarios are possible. One of such scenarios is both UA sending UPDATE at the same time. If these UPDATE requests do not carry SDP, currently they should be accepted. Resulting session timer state is ambiguous. The only reliable way to prevent ambiguous session timer state in this case is to refuse the UPDATE message, similar to the session description collision. This is why 491 was suggested. First of all, is a 491 rejected solution planned for bis? If so, the UPDATE for target-refresh and the one for session-refresh are combined, as such they affect each other. And I think the result will be rarely ambiguous, if there is no change in the session timer policy of each entity(UAC, proxies and UAS). Even so, should UAs reject the UPDATE request? If the UPDATE with new remote-target-uri is rejected, the UA will be unreachable. >> 2. Handling of UPDATE transactions during initial INVITE >> RFC6141 says, if in doubt, send a refresh request to confirm. > This is exactly the reason why handling of UPDATE transaction collisions needs to be resolved. If session timer ends up in an ambiguous state, it is likely ambiguous for both UA and both UA will initiate an UPDATE refresh request to confirm, which will result in a collision. I suggest the method in RFC3261 Section 14.1 as a procedure to avoid collisions on retransmission. And we also need to decide how UAs detect collisions. Regards, Shinji From nobody Wed Jun 24 02:22:48 2020 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 756C13A0CC6 for ; Wed, 24 Jun 2020 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PeLgeAlHYCy for ; Wed, 24 Jun 2020 02:22:46 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 338803A0CC5 for ; Wed, 24 Jun 2020 02:22:46 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id a45so2139416pje.1 for ; Wed, 24 Jun 2020 02:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=fXt0Z5sMfyT6AyPB48TKbEgxJPj7q13cETA5MsScDq8=; b=VKAiBLdYOXafSCBiIYoaiPj0KVaHTayUkZOs6HYX3fY63fwI37uZwQSlcvOaeP/B95 sdzWzXCi481ePkkWLlYGq9VMwQR3FkyIoPkHI8c3faONbcxekiqsjzdm0bAeo+tYIHny sV6T3yuScZrdou4IVhs97v4kcdKBmUEKP14zT+o4SO0ALW/9N8O5LYnw8yIAGey0NCw5 duoFf2bZ903SB/pfDYmKAphh2qhkGjodCCzspon7Vgvz34Lrim2pp9/OzDQmWLVW0lkU aYN3fxsyvNFMK6M+1WJnNad0TbkK69oV8Uozy5LUVuc8572wEYfN3HpeJHZScBkYfZY8 4t1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=fXt0Z5sMfyT6AyPB48TKbEgxJPj7q13cETA5MsScDq8=; b=A2vcWiIo0wnC3105UA+xQeVVRZ6lHYIy44GvSuXQJDHgx3BDhNrE47X9xosFR87ZY9 MwFBQhuId9LJi42BMlWTFG18RfObSNIVSh4LORRKvBrHvcT5g0vXyd4IZz5xBvwAzW// YtO8mpCZmyT01y4/1peYQpuaDXS+VL+wkzjjePSS/NL4zG+X1Li1tYJ9I1JDm888M9Yl wy8xEWnyluAgt4TOYxuaGrTAyh791LkV60yc9sq9fF3mdISIJSLXqxRhe9DDRVuNU9Pz uOndzlsTDj6cE49wBlS6gCj+vghtMJFxiZs2S84LmhN28DyXEewZ9MXyLG3Ws+Ms0167 0hXw== X-Gm-Message-State: AOAM533Z1cpQuAzUcMw7imZAYx091oAPjBa0vj2SnmAwTLJR6XOkNnMh TiYgiE8aHdj1bogYRDbGEQi5CpWF X-Google-Smtp-Source: ABdhPJwtgk102IT6hZhKhI/P5tQPm47EfPNxQJEWRM2ESrVfTRykFm8sIVZkA0/mEwMq2yfv7lYXpg== X-Received: by 2002:a17:902:b60f:: with SMTP id b15mr27761490pls.248.1592990565402; Wed, 24 Jun 2020 02:22:45 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id z14sm19479939pfj.64.2020.06.24.02.22.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 02:22:44 -0700 (PDT) To: "sipcore@ietf.org" From: OKUMURA Shinji Message-ID: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> Date: Wed, 24 Jun 2020 18:22:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 09:22:48 -0000 Hi, 7.4. Generating Subsequent Session Refresh Requests ===================================================================== In a session refresh request sent within a dialog with an active session timer, the Session-Expires header field SHOULD be present. When present, it SHOULD be equal to the maximum of the Min-SE header field (recall that its default value when not present is 90 seconds) and the current session interval. Inclusion of the Session-Expires header field with this value avoids certain denial-of-service attacks, as documented in Section 11. As such, a UA should only ignore the SHOULD in unusual and singular cases where it is desirable to change the session interval mid-dialog. ===================================================================== 1. Why SHOULD the Session-Expires header field be present? A UA1 sent an initial INVITE without a Session-Expires header, then UA1 became a refresher. UA1 didn't a session-timer, and so it did not add a Session-Expires header to the INVITE. As a perspective of UA, adding a Session-Expires header means that it own needs a session-timer. But UA1 doesn't need it even now. In this situation, why SHOULD the Session-Expires header field be present? 2. What SHOULD the value be equal to? In general, the maximum of the Min-SE header field is not equal to the current session interval. It is ambiguous. In the first place, a UAC doesn't always know the exact maximum. 3.Why dose inclusion of the Session-Expires header field with this value avoid certain denial-of-service attacks? Section 11.1 says: ===================================================================== Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. ===================================================================== As I pointed out earlier, if the rogue UAS returns a 2xx with a very small session interval again, the attack will continue. IMO the important point is that UAs need to know the maximum value of the Min-SE header field in the dialog. According to the current regulations, only the UAS can know the maximum value. I think that 2xx response should include Min-SE header. And proxies should check it. Regards, Shinji From nobody Wed Jun 24 07:18:17 2020 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 404FF3A0E07 for ; Wed, 24 Jun 2020 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 uPJSeD0HtKSS for ; Wed, 24 Jun 2020 07:18:05 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 80BBE3A0E06 for ; Wed, 24 Jun 2020 07:18:05 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id 5so41948oty.11 for ; Wed, 24 Jun 2020 07:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HGlzaDcMMhGScnKCMqz8pYuC1TCDQrgXlNAwtElJKyA=; b=0ZUoT6FkCV5xaOCxq04RSmkXFN+A6fXNC84M6CwB8SSjMhlRBn5jOHgvbnXK9dfBU6 VDroRhP87YA7OMZHJtP39UvurAwuTFXomkdN58jzTrIJYL5RLI5TvrTxsIhqvodT2tSH 2hmZdsNmF9c0xE9NksjCqSuE4PZLml1jj/CfMjhnjL88XRHGaEsfgfuk5QOd6JC8rVqN 2vRKF91cFj8hyUB/3ngVaV58Jq3e6Y8tQAVudzdLH+DnCcGEewWdkm4Wrqe1tVqJqDmc ZETa5FrupLn8PI7dgkLyKPtVw9ICvOtrPUbSx+XvlR9YMcVK5AViA2rmwZ357cEjRtec SRPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HGlzaDcMMhGScnKCMqz8pYuC1TCDQrgXlNAwtElJKyA=; b=WdtF+ZPGgSW+xhIHtmcrrCjKqYPKRLmRtF8ViolR/1AKXwUXkTPuDU6o6k64CLjLmJ LSzvHFyGxsC/sxig4r10v3OhzGAQXGvY0NfkP6b2PDZuobw5nvavaUUjzeLAo2hgCnZ8 ZdUkhYbdGOmQ8bmLh2MTWplfrhgVjLDxFQ0jPk48b6zSVH2xf3Ept55AMneuTsSRwyKK YR4Z2jXS/i1GjvQjnpIOApMxloUsrkrz2eUpbrmvPqd3jGxfEyIG4H7gFF/V/IgXSmPH aNo7hVUYPUnH5VCMy1G5i3oOmE7Td4Wa13QcthZaksjFHM4IbflWnWb82UJCPfNKZTK0 bBYQ== X-Gm-Message-State: AOAM5327QJZOr34io1tW4TKKZlglapmqpkISH1JcyLGAGaW8vr3AH1lj eU44+wXNOwV8e3iOcX17yFvj56DJF7k= X-Google-Smtp-Source: ABdhPJzRbwTU17ATwpNepk82NwfSPp7TlixP8vc2pO4tjiM6psyvvYXALN+M6EMD5UZ75QDoIC35Wg== X-Received: by 2002:a9d:d13:: with SMTP id 19mr24146093oti.83.1593008284134; Wed, 24 Jun 2020 07:18:04 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com. [209.85.167.180]) by smtp.gmail.com with ESMTPSA id v28sm4952870ooe.26.2020.06.24.07.18.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 07:18:03 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id s21so1934872oic.9 for ; Wed, 24 Jun 2020 07:18:03 -0700 (PDT) X-Received: by 2002:aca:72c2:: with SMTP id p185mr20952028oic.139.1593008282709; Wed, 24 Jun 2020 07:18:02 -0700 (PDT) MIME-Version: 1.0 References: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> In-Reply-To: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> From: Roman Shpount Date: Wed, 24 Jun 2020 10:17:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d0b3b705a8d52452" Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 14:18:15 -0000 --000000000000d0b3b705a8d52452 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 5:23 AM OKUMURA Shinji wrote: > 1. Why SHOULD the Session-Expires header field be present? > A UA1 sent an initial INVITE without a Session-Expires header, then UA1 > became a refresher. > UA1 didn't a session-timer, and so it did not add a Session-Expires header > to the INVITE. > As a perspective of UA, adding a Session-Expires header means that it own > needs a session-timer. > But UA1 doesn't need it even now. In this situation, why SHOULD the > Session-Expires header field be present? > This is an optimization. Setting Session-Expires to an existing session timer value avoids session timer re-negotiation and potential 422 responses. 2. What SHOULD the value be equal to? > In general, the maximum of the Min-SE header field is not equal to the > current session interval. > It is ambiguous. In the first place, a UAC doesn't always know the exact > maximum. > It is the maximum of Min-SE set by UAC and the current Session-Expires value for the dialog. UAC knows both. 3.Why dose inclusion of the Session-Expires header field with this value > avoid certain denial-of-service > attacks? > > Section 11.1 says: > ===================================================================== > Next, consider the case of a rogue UAS that wishes to force a UAC to > generate refreshes at a rapid rate. In that case, the UAC has to > support session timer. The initial INVITE arrives at the rogue UAS, > which returns a 2xx with a very small session interval. The UAC uses > this timer and quickly sends a refresh. Section 7.4 requires that > the UAC copy the current session interval into the Session-Expires > header field in the request. This enables the proxies to see the > current value. The proxies will reject this request and provide a > Min-SE with a higher minimum, which the UAC will then use. > ===================================================================== > > As I pointed out earlier, if the rogue UAS returns a 2xx with a very small > session interval again, the attack will continue. IMO the important point > is that UAs need to know the maximum value of the Min-SE header field in > the dialog. According to the current regulations, only the UAS can know the > maximum value. I think that 2xx response should include Min-SE header. And > proxies should check it. > In general I agree but it is not an entirely backwards compatible change. _____________ Roman Shpount --000000000000d0b3b705a8d52452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 24, 2020 at 5:23 AM OKUMURA S= hinji <ietf.shinji@gmail.com> wrote:
1. Why SHOULD the Session-Expires header field be p= resent?
A UA1 sent an initial INVITE without a Session-Expires header, then UA1 bec= ame a refresher.
UA1 didn't a session-timer, and so it did not add a Session-Expires hea= der to the INVITE.
As a perspective of UA, adding a Session-Expires header means that it own= =C2=A0 needs a session-timer.
But UA1 doesn't need it even now. In this situation, why SHOULD the Ses= sion-Expires header field be present?
This is an optimization. Setting Session-Expires to an existing session ti= mer value avoids session timer re-negotiation and potential 422 responses.<= /div>

2. Wh= at SHOULD the value be equal to?
In general, the maximum of the Min-SE header field is not equal to the curr= ent session interval.
It is ambiguous. In the first place, a UAC doesn't always know the exac= t maximum.
=C2=A0
It is the maximum of Min-S= E set by UAC and the current Session-Expires value for the dialog. UAC know= s both.

3.Why dose inclusion of the Session-Expires header field with this value= avoid certain denial-of-service
attacks?

Section 11.1 says:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Next, consider the case of a rogue UAS that wishes to force a UAC to
generate refreshes at a rapid rate.=C2=A0 In that case, the UAC has to
support session timer.=C2=A0 The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval.=C2=A0 The UAC uses<= br> this timer and quickly sends a refresh.=C2=A0 Section 7.4 requires that
the UAC copy the current session interval into the Session-Expires
header field in the request.=C2=A0 This enables the proxies to see the
current value.=C2=A0 The proxies will reject this request and provide a
Min-SE with a higher minimum, which the UAC will then use.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As I pointed out earlier, if the rogue UAS returns a 2xx with a very small = session interval again, the attack will continue. IMO the important point i= s that UAs need to know the maximum value of the Min-SE header field in the= dialog. According to the current regulations, only the UAS can know the ma= ximum value. I think that 2xx response should include Min-SE header. And pr= oxies should check it.

In general I agr= ee but it is not an entirely backwards compatible change.
_____________
Roman= Shpount=C2=A0
--000000000000d0b3b705a8d52452-- From nobody Wed Jun 24 12:20:09 2020 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 6D2A53A092F for ; Wed, 24 Jun 2020 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 jEJdxAmpu3Gj for ; Wed, 24 Jun 2020 12:20:06 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 BFF393A094B for ; Wed, 24 Jun 2020 12:20:06 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id 5so1000933oty.11 for ; Wed, 24 Jun 2020 12:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vbw03SMIo6Mo9WQVvg5swkuEBI0zjZuFCEYfmtlHo2g=; b=oLrVbpM+tptVk/E3XDCxAxaHxoktplaEy+rrLhIghMsBWXm6bGNn7CubCiizRu+1fE 1Bmluvt41CIIitwmkMoMluXq6xxo+iN4Yt1Y2mptPl0237lgKhdHt3qj6lZzY4MkJvDv lppmHyAUHloCDZoVY4oe+qQIWjAF9obPx8enOh2p5ymWqn1UKWTlKpSbudlFtcfbQsmj 4V0SWNkH9hFByTU+LbE7FXaKAcd4iTwwGI467UmbABiE9zL4j4yGrvgi7nt4kJErflbI btcmntWw07TA/SdOVKC3sSyKYBRYOO+B6YRk2cJhME+RUk3V5BNGdYsFdkTQOM/XUXOF 9XwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vbw03SMIo6Mo9WQVvg5swkuEBI0zjZuFCEYfmtlHo2g=; b=ooP3ywykp/ZQRVWEykvWRKq81usuvLZjlINvv2mLKIW4IwSpFW6ulMOpxM2YCMGYE7 jGo9FSgJa2bA+Ck5aXOnjhYAPVntAIgtkDGiudzzo4+RN2MBS+jG6cadwLPzoxqhrki+ AjOTDcYjvSnbObYwKeTuVz7PTqhRcJhkZgDEaYpESMXH3tHarGX6UwwYYWUGAuzh6Qvz o483tN9KoQ7kI33lrFs94j4w2XSCO6nvjDfT/skxbciufsBk2dMX4ZZ8ThKyF1GaG4Dq ZgOJfPYYSMBT6UuRMImK4lvtVDaQzn75+hGW0+l6gphHSLckaaqZ8NA1kpXDChBw0OXp XVJQ== X-Gm-Message-State: AOAM531HfgqHs1p8xel9ON/73qks5N4NSppHcA3/PnNBDoWp6pyN9zuO D4a1myPpVEShujZZ2rzD5vyKpdYOBUQ= X-Google-Smtp-Source: ABdhPJzrg+6XY+3F4pIXdLQnKiTa82qLqdMOkaO1xTwlGprAzwg0DT/PL80SW1r9B4DZtDF2v2OBsA== X-Received: by 2002:a9d:427:: with SMTP id 36mr23245454otc.294.1593026405377; Wed, 24 Jun 2020 12:20:05 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com. [209.85.167.181]) by smtp.gmail.com with ESMTPSA id j2sm4960670oiw.24.2020.06.24.12.20.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 12:20:04 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id a3so2828145oid.4 for ; Wed, 24 Jun 2020 12:20:03 -0700 (PDT) X-Received: by 2002:aca:c690:: with SMTP id w138mr18626582oif.12.1593026403449; Wed, 24 Jun 2020 12:20:03 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> In-Reply-To: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> From: Roman Shpount Date: Wed, 24 Jun 2020 15:19:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE , Paul Kyzivat Content-Type: multipart/alternative; boundary="000000000000e5422e05a8d95c3a" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 19:20:08 -0000 --000000000000e5422e05a8d95c3a Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji wrote: > >> 1. Handling of UPDATE with no SDP glare > >> I'm not going to deny the solution with the 491 response, but I think > it has a big impact. > > > > The situation with session timers is different from target refresh. > Target refresh is updated for each UA independently. Session timer is > negotiated for the entire session, so more collision scenarios are > possible. One of such scenarios is both UA sending UPDATE at the same time. > If these UPDATE requests do not carry SDP, currently they should be > accepted. Resulting session timer state is ambiguous. The only reliable way > to prevent ambiguous session timer state in this case is to refuse the > UPDATE message, similar to the session description collision. This is why > 491 was suggested. > > First of all, is a 491 rejected solution planned for bis? > It was discussed but nothing is final. > If so, the UPDATE for target-refresh and the one for session-refresh are > combined, as such they affect each other. And I think the result will be > rarely ambiguous, if there is no change in the session timer policy of each > entity(UAC, proxies and UAS). Even so, should UAs reject the UPDATE > request? If the UPDATE with new remote-target-uri is rejected, the UA will > be unreachable. > This should be no different than the UPDATE with SDP collision. I am not sure what problem you are talking about. >> 2. Handling of UPDATE transactions during initial INVITE > >> RFC6141 says, if in doubt, send a refresh request to confirm. > > This is exactly the reason why handling of UPDATE transaction collisions > needs to be resolved. If session timer ends up in an ambiguous state, it is > likely ambiguous for both UA and both UA will initiate an UPDATE refresh > request to confirm, which will result in a collision. > > I suggest the method in RFC3261 Section 14.1 as a procedure to avoid > collisions on retransmission. And we also need to decide how UAs detect > collisions. > I am not sure what you are talking about. _____________ Roman Shpount --000000000000e5422e05a8d95c3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> 1. Handling of UPDATE with no SDP glare >> I'm not going to deny the solution with the 491 response, but = I think it has a big impact.
>
> The situation with session timers is different from target refresh. Ta= rget refresh is updated for each UA independently. Session timer is negotia= ted for the entire=C2=A0session, so more collision=C2=A0scenarios are possi= ble. One of such scenarios is both UA sending UPDATE at the same time. If t= hese UPDATE=C2=A0requests do not carry SDP, currently they should be accept= ed. Resulting session timer state is ambiguous. The only reliable way to pr= event ambiguous session timer state in this case is to refuse the UPDATE me= ssage, similar to the session description collision. This is why 491 was su= ggested.

First of all, is a 491 rejected solution planned for bis?
<= div>
=C2=A0<= /div>
If so, the UPDATE for target-refresh and the one for session-refresh are co= mbined, as such they affect each other. And I think the result will be rare= ly ambiguous, if there is no change in the session timer policy of each ent= ity(UAC, proxies and UAS). Even so, should UAs reject the UPDATE request? I= f the UPDATE with new remote-target-uri is rejected, the UA will be unreach= able.

=C2=A0This should be no different= than the UPDATE with SDP collision. I am not sure what problem you are tal= king about.

>> 2. Handling of UPDATE transactions during initial INVITE >> RFC6141 says, if in doubt, send a refresh request to confirm.
> This is exactly the reason why handling of UPDATE transaction collisio= ns needs to be resolved. If session timer ends up in an ambiguous=C2=A0stat= e, it is likely ambiguous for both UA and both UA will initiate an UPDATE r= efresh request to confirm, which will result in a collision.

I suggest the method in RFC3261 Section 14.1 as a procedure to avoid collis= ions on retransmission. And we also need to decide how UAs detect collision= s.

I am not sure what you are talking a= bout.=C2=A0
__________= ___
Roman Shpount=C2=A0
--000000000000e5422e05a8d95c3a-- From nobody Wed Jun 24 14:17:29 2020 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 C5EFB3A119A for ; Wed, 24 Jun 2020 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 nuq7vShMeh0h for ; Wed, 24 Jun 2020 14:17:25 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640110.outbound.protection.outlook.com [40.107.64.110]) (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 204C23A117D for ; Wed, 24 Jun 2020 14:17:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MJSSAebTgGEKtzl77BGWtTDv72Or8qv5w0OKBt3lWUZlfLGboFLG6uWSSOKxlIi5SDpqTTblf7cpQ0W9OvYdccrkf95Nb27cLqVG9aJ97dz4f/cl6cVXZ3V8cXCSIHDL37nnFwQxhycZ/ptw2FrzZFNMyTM7jfYfPwM84cvbPB3OImeM8aQiB2xuvQIrT2WihoWXto9erxWY448BswjwVOYEo3wZRXMsF+Y2vKNHxG4Xl+UsRk8SzyV7fcEElx2chgPmF7cAVc7z8MbMk1FCRM8vbedhDuRpgwWi9BD5I+ic/IJuarTLdzjQCUeLdCT0xtoldog+ScbglrjlVRATNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=01qrkq3DPL2HJIFVphLkfBOTdXzodp45JHjF28JUvM0=; b=myjqhR+p7BN1957S7v5q9Nv2Ua0wEUcWCsF0EefHglMf2wbkJae/f958bK7E/ihN7x8tQoHlKFrPyGQCaRibAKkvFUH4XtjWWkPG0JorN8/Q7R1hfBiqSVlZSEXKlRaI/4sbsJUZY+ZuBwUYFvJkWN0NMFJ5AfnWTFrP0om8IFw5DlzZdHCzyto4cxX0+o2RrZU4GXHBF8QFuFMMvEYOxDbo5z2AV8G1NnvaxIDeWRdUunSnbIZ98nI5iitOFiMCnEaY2oce1UnuV1Sp97fJUkfXpelgwjEF0SvdhzKhFeTME/XYMUsUjPBe9R6lWCXixQYc63sTRP9sCPS/tjrHhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=01qrkq3DPL2HJIFVphLkfBOTdXzodp45JHjF28JUvM0=; b=AdgsRILGj/20MRVhiNdk5duJi7QzRGQiADkocni74iCMBxvNjtnLRf7LdQR8AlKagdtZ3BQrTODy/1LDer6J/VY30ywBahFVxuI2KLDwlqUkqPdI0wpBqpiY+0PmOpku1L4Iq67GD70oh6W9cB6YhX2qp/v5GV36TdHn5deedAo= Received: from MW2PR00MB0428.namprd00.prod.outlook.com (2603:10b6:302:b::16) by CO2PR00MB0072.namprd00.prod.outlook.com (2603:10b6:102:18::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3167.0; Wed, 24 Jun 2020 21:17:23 +0000 Received: from MW2PR00MB0428.namprd00.prod.outlook.com ([fe80::1421:1465:ca19:bc63]) by MW2PR00MB0428.namprd00.prod.outlook.com ([fe80::1421:1465:ca19:bc63%4]) with mapi id 15.20.3171.000; Wed, 24 Jun 2020 21:17:23 +0000 From: Russ Penar To: Richard Shockey , "sipcore@ietf.org" Thread-Topic: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AQHWSAb/NQH6nkrse0mtDj84GaxpM6jjqSKVgARxwHA= Date: Wed, 24 Jun 2020 21:17:23 +0000 Message-ID: References: <5D3B2CCC-4801-4DB8-89A4-D29ED628669D@shockey.us> <54D854A7-1A68-4F2A-8CC7-04AD3EA3730B@shockey.us> In-Reply-To: <54D854A7-1A68-4F2A-8CC7-04AD3EA3730B@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=836dc87a-160c-4f19-b3c8-0f2004065733; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-24T18:30:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: shockey.us; dkim=none (message not signed) header.d=none;shockey.us; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.243.40.32] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70f5b4b7-b67b-415b-8b44-08d81883fcc5 x-ms-traffictypediagnostic: CO2PR00MB0072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y/0N4ubj6/cG/glrqdsKcaIHZk6tyuCyaRwneuAB65JGXH8kROB9vjLgGFQO29Mr1od231ANvlxLag/Fp60Wu2Q80UuJsItz7lkP0Ic2N0CJT4dDjMmKorkZKzxsck2iGNNIoBcLCteX7yB8if965iNLLNhAL9BRziFPb2JnXsFpT+u4WyaUdzotTboNQrOAaVKF9AVOhxMm0YiOin3Wj9Hi4LV/kSbm1KlSkAkTq2O1noEeRDOpGi7olSequwK/yS9z2oYGcSxO0enOF7+5ATjYy14Q/lpDT6hds7C7yN5gIpq3oiQFC1iEReYlggMdS+sPPdOw/f8bXpo0BBe9dZzq8g+gYxe2pEEIsO91UziFgH17XdXtydEXOgys/lD/i8y8E1msCiMHtKcTzLoFOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0428.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(396003)(39860400002)(366004)(376002)(966005)(5660300002)(82960400001)(82950400001)(77540400001)(52536014)(9686003)(8990500004)(16799955002)(316002)(478600001)(7696005)(8676002)(8936002)(76116006)(64756008)(66476007)(66556008)(66446008)(55016002)(26005)(71200400001)(86362001)(110136005)(83380400001)(66946007)(53546011)(6506007)(186003)(10290500003)(2906002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Ly49cuC9+pChN8cpGoRYtZnWdXrtpVSDZMP+7jFJ2OsUnTZ6lsksJ+El3/5vA5zD3xJW0koz3X/7QKrgzOU1hN3YpuuFPaQ2J3bkqVjjJH/P/GgWRKHz7TdkUwyqR2ZhEvd+l7A5sFDh/1pUerNhz55sAZwXq/gUZ+iuJivBVr5TiMBv2q7Yyt2LORMYeRXahWnI0pJ7FXh06XnD/qW+ZwslYTipUYHw+JEbAdHdWl1zeSaEs8atbZEFQljcnlMmiAZs25GWU3QHrHhbs0sRD8sARk+DmGGRpk8hHovk/TYzq4TlQmZEkl4dwD6s5JQu1yGK9Tg04LzHcZycV1ZWH+7g1zufloEr1sSw+jIfHaNc8q2ZD7mfNyWCX4HNLxcnudlxMSQAI9o7hzep62/G7LopjDSw/HCvzmlQl6WOqdD4ZuvcIUxX2VPl0jMcCox6pzgBqeL14ig0HgJiT7AeRWpg3WNmuD19M90QvYF4HEo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0428.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70f5b4b7-b67b-415b-8b44-08d81883fcc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 21:17:23.1853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B1XgLCJ5MkDU5/NOzTxOs5a+D4ogUecouqVEW1drTzzLSAiAnyjR10q6ZVdaFQUzHfxLJhTls0ytTz9RHDTdOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0072 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 21:17:28 -0000 VGhhbmsgeW91IFJpY2ggYW5kIFBpZXJjZSENCg0KQ291cGxlIHRob3VnaHRzIGJhc2VkIG9uIGRp c2N1c3Npb25zIHRodXMgZmFyOw0KDQoxKSBJJ2QgbGlrZSB0byBwcm9ncmVzcyAxeHggJ3JhdGVk JyBkcmFmdCwgcGxlYXNlIHNlZSBsYXRlc3QgcmV2aXNpb24gKDAxKS4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVuYXItc2lwY29yZS1yYXRpbmdwcm92aWRlZC8NCjIp IEknbSBvcGVuIHRvIHBhcnRuZXIgd2l0aCBpbnRlcmVzdGVkIGZvbGtzIG9uIG90aGVyIHByb3Bv c2FscyBpbiB0aGUgc2FtZSBjb250ZXh0LCB2aWEgc2VwYXJhdGUgZHJhZnRzLiANCglhKSBEYWxl IGFuZCBQaWVyY2UgaWRlYXMgb24gdG9rZW4gZXhjaGFuZ2UgIC0gRnVuIG5hbWVzIHNwcmluZ2lu ZyB0byBtaW5kIGFyZSAoYm9uZCkgSkFXUyAtIEood3MpIEF1dGhvcml6YXRpb24gV2l0aCBTKGlw KSAuLiBhbmQgIChib25kICYgYm9vemUpIFNIT1QgLSBTaWduZWQgSGFzaGVkIE9mZmVyIFRva2Vu DQoJYikgUnlhbi9TdGV2ZSdzIGlkZWEgb24gY29uc3VtaW5nIGFuZCByZWZhY3RvcmluZyBmaW5h bCByZXNwb25zZXMNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBj b3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWNoYXJkIFNob2Nr ZXkNClNlbnQ6IFN1bmRheSwgSnVuZSAyMSwgMjAyMCAzOjM4IFBNDQpUbzogc2lwY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbRVhURVJOQUxdIFJlOiBwbGVhc2UgcmV2aWV3 IGFuZCBjb21tZW50IG9uIGRyYWZ0LXBlbmFyLXNpcGNvcmUtcmF0aW5ncHJvdmlkZWQtMDANCg0K DQoNClRoZSByZWFsIGFkdmFudGFnZSBoZXJlIGlzIHRoZSB1c2UgY2FzZSBvbmx5IGxvb2tzIGxp a2UgYSBCQ1AgYW5kIHdlIGRvbuKAmXQgZ2V0IHRyYXBwZWQgaW50byB0aGUgZW5kbGVzcyBmaWdo dCBvdmVyIGEgbmV3IFNJUCByZXNwb25zZSBjb2RlLg0KDQpUaGlzIGlzIGluIHBlcmZlY3QgYWxp Z25tZW50IHdpdGggUkZDIDg2ODggYWthIHRoZSBTSVAgNjA4IHJlamVjdGVkIGVycm9yIGNvZGUu ICBJZiBTUCdzIHdhbnQgdG8gdXNlIGl0IGZpbmUgaWYgdGhleSBkb24ndCBPSyBidXQgSSBkbyBr bm93IHdoYXQgdGhlIHJlZ3VsYXRvcnMgbWlnaHQgdGhpbmsuIA0KDQpBbmQgeW91cnMgdHJ1bHkg d2lsbCBiZSBkZWFsaW5nIHdpdGggdGhhdCB0b21tcnJvdy4gDQoNCmh0dHBzOi8vbmFtMDYuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5zaXBm b3J1bS5vcmclMkZuZXdzLWV2ZW50cyUyRnN0aXItc2hha2VuLXZpcnR1YWwtc3VtbWl0JTJGc2No ZWR1bGUlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3QzcyY2Rh NTU5N2M2NTRmMWEyODY3MDhkODE2MzNiOWM1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MwJTdDMCU3QzYzNzI4Mzc1ODY5ODc1OTgwNCZhbXA7c2RhdGE9ZHJhJTJGODFuUW13 RzRSQjI4WEpKWFZ0RmxoODRXZTRRcE1xZ2ZhTyUyQktONFklM0QmYW1wO3Jlc2VydmVkPTANCg0K IA0KRm9yIHRoZSByZXN0IG9mIHlvdSBmb2xrcyB3ZSBkbyBrbm93IHdoYXQgdGhlIHVzZSBjYXNl IGlzIGl04oCZcyB0aGUgVVMgVFJBQ0VEIGFjdC4gIFdlIGhhdmUgYSBsZWdpc2xhdGl2ZSBtYW5k YXRlIGFuZCBpdHMgZ29pbmcgdG8gYmUgZW5mb3JjZWQuIEl0IGFsc28gbWlnaHQgcHVzaCBmb3J3 YXJkIHRoZSBpc3N1ZSBvZiBhbGwgSVAgaW50ZXJjb25uZWN0aW9uLiAgDQoNCkZpbG0gYXQgMTEu IA0KDQpJTUhPIHRoaXMgbmVlZHMgdG8gZ2V0IGZvcm1hbGl6ZWQgaW4gU0lQQ09SRSBBU0FQLiAg SSB0aGluayBSdXNzIG5lZWRzIHRvIHdlaWdoIGhpcyBvcHRpb25zIGhlcmUgYW5kIGxldHMga2Vl cCB0aGUgZGlzY3Vzc2lvbiBnb2luZyBidXQgSSdsbCBjZXJ0YWlubHkgc3VwcG9ydCBzb21lIGtp bmQgb2YgZHJhZnQgYWxvbmcgdGhlc2UgbGluZXMgYXMgYSBmb3JtYWwgU0lQQ09SRSBXRyBpdGVt LiAgIFRoZXJlIGlzIG5vIG5lZWQgdG8gZ28gdG8gRElTUEFUQ0ggb24gdGhpcy4gDQoNCkFzIGZv ciBzb21ldGhpbmcgY2F0Y2h5IC4uIENSRUFNIHJlYWxseSA/IFdoZXJlIGlzIHRoZSBsaXF1b3Ig Y29tcG9uZW50LiAgQWxsIG5ldyBTSVAgcHJvdG9jb2xzIG9yIGV4dGVudGlvbnMgTVVTVCBoYXZl IGEgcmVmZXJlbmNlIHRvIGJvb3plIG9yIEphbWVzIEJvbmQuIA0KDQrvu79PbiA2LzIxLzIwLCA0 OjQ3IFBNLCAiR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSIgPFBpZXJjZS5Hb3JtYW5AdC1tb2JpbGUu Y29tPiB3cm90ZToNCg0KICAgIE1lIHRvbyENCg0KICAgIEVuZCBlbnRpdGllcyBleGNoYW5naW5n IGluZm9ybWF0aW9uIGVsZW1lbnRzIHRoYXQgY291bGQgYmUgdXNlZCB0byBhdXRoZW50aWNhdGUg YW5kIGF1dGhvcml6ZSBhIGNvbW11bmljYXRpb25zIGF0dGVtcHQgc291bmRzIGdvb2QgdG8gbWUu ICBXZSBuZWVkIGEgY2F0Y2h5IGFjcm9ueW0uICBJJ2xsIHZvbHVudGVlciBTSUdORVQuDQoNCiAg ICBIbW1tLCBvbiBzZWNvbmQgdGhvdWdodCwgc2luY2UgaXQncyBiYXNlZCBvbiBTSVAsIG1heWJl IHdlIHNob3VsZCB1c2UgQ1JFQU07IENvbW11bmljYXRpb25zIFJlbGF0aW9uc2hpcCBFeHRlbnNp YmxlIEFkZHJlc3MgTWV0aG9kLg0KDQogICAgaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGYWNjZXNzLmF0aXMub3JnJTJGYXBw cyUyRmdyb3VwX3B1YmxpYyUyRmRvY3VtZW50LnBocCUzRmRvY3VtZW50X2lkJTNENDMyOTUmYW1w O2RhdGE9MDIlN0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3QzcyY2RhNTU5N2M2NTRmMWEy ODY3MDhkODE2MzNiOWM1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdD MCU3QzYzNzI4Mzc1ODY5ODc2OTc5OCZhbXA7c2RhdGE9YTU1RFRDelI5bXJyczE3clhySVdsNld3 anVJdVd2ayUyQiUyRkNjJTJGakViN2NXOCUzRCZhbXA7cmVzZXJ2ZWQ9MCAgIFNlZSBzbGlkZSAj OC4NCg0KICAgIFBpZXJjZQ0KDQoNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAg IEZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJp Y2hhcmQgU2hvY2tleQ0KICAgIFNlbnQ6IFN1bmRheSwgSnVuZSAyMSwgMjAyMCAzOjAzIFBNDQog ICAgVG86IFJ1c3MgUGVuYXIgPHJ1c3NwPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz47 IERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQog ICAgU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbRVhURVJOQUxdIFJlOiBwbGVhc2UgcmV2aWV3IGFu ZCBjb21tZW50IG9uIGRyYWZ0LXBlbmFyLXNpcGNvcmUtcmF0aW5ncHJvdmlkZWQtMDANCg0KDQog ICAgSSByZWFsbHkgbGlrZSB0aGlzIGlkZWEgYXMgd2VsbC4gDQoNCiAgICDigJQgDQogICAgUmlj aGFyZCBTaG9ja2V5DQoNCiAgICBTaG9ja2V5IENvbnN1bHRpbmcgTExDDQoNCiAgICBDaGFpcm1h biBvZiB0aGUgQm9hcmQgU0lQIEZvcnVtDQoNCiAgICBodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy5zaG9ja2V5LnVzJTJG JmFtcDtkYXRhPTAyJTdDMDElN0NydXNzcCU0MG1pY3Jvc29mdC5jb20lN0M3MmNkYTU1OTdjNjU0 ZjFhMjg2NzA4ZDgxNjMzYjljNSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MCU3QzAlN0M2MzcyODM3NTg2OTg3Njk3OTgmYW1wO3NkYXRhPXUwTEFEdHl0bkclMkZIZVZhcTJ3 S3lLR2VaOUtZa1NLTW1MWHdWRFlaOWQ4cyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQogICAgaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZ3d3cuc2lwZm9ydW0ub3JnJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NydXNzcCU0MG1pY3Jvc29m dC5jb20lN0M3MmNkYTU1OTdjNjU0ZjFhMjg2NzA4ZDgxNjMzYjljNSU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMCU3QzAlN0M2MzcyODM3NTg2OTg3Njk3OTgmYW1wO3NkYXRh PU5HSUJQbTlMZTFwS1VOUnVadDc3ZkxYems1N0ozaDY2ZDNuZkRZcFI4cTAlM0QmYW1wO3Jlc2Vy dmVkPTANCg0KICAgIHJpY2hhcmQ8YXQ+c2hvY2tleS51cw0KDQogICAgU2t5cGUtTGlua2VkaW4t RmFjZWJvb2sg4oCTVHdpdHRlciAgcnNob2NrZXkxMDENCg0KICAgIFBTVE4gKzEgNzAzLTU5My0y NjgzDQoNCg0KDQogICAg77u/T24gNi8xNi8yMCwgNzo1MSBQTSwgInNpcGNvcmUgb24gYmVoYWxm IG9mIFJ1c3MgUGVuYXIiIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJ1 c3NwPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICAgICAgVGhh dCBpcyBhbiBpbnRlcmVzdGluZyBpZGVhIERhbGUgdGhhbmsgeW91LCAgDQoNCiAgICAgICAgVGhl IHNwaXJpdCBvZiBteSBwcm9wb3NhbCBpcyBzb21ldGhpbmcgdG8gaGVscCBvdXQgc3BlY2lmaWNh bGx5IGluIHRoZSBjdXJyZW50IGNhbGwgYW5hbHl0aWNzIGVudmlyb25tZW50LCBhbmQgaXMgaG9w ZWZ1bGx5IGxpZ2h0d2VpZ2h0IHRvIGltcGxlbWVudC4gIFRoYXQgc2FpZCwgYXMgSSByZWFkIHRo cm91Z2ggeW91ciBlbWFpbCBhIGNvdXBsZSBxdWVzdGlvbnMgY2FtZSB0byBtaW5kLg0KDQogICAg ICAgICIuLiB0b2tlbiBpbiB0aGUgSU5WSVRFIHdoaWNoIHdvdWxkIGJlIHJlY29yZGVkIHdpdGgg dGhlIHZvaWNlbWFpbCBtZXNzYWdlIHRvIHRoZSBjYWxsZWUgQi4iDQoNCiAgICAgICAgU2hvdWxk IHRoZXJlIGJlIGFueSBhc3N1bXB0aW9uIGFib3V0IHVuYW5zd2VyZWQgY2FsbHMgJ2Fsd2F5cycg Z29pbmcgdG8gdm9pY2VtYWlsPyAgUGVyaGFwcyBpdHMgYW4gZXhjZXB0aW9uIGNhc2UsIGJ1dCBj dXJpb3VzIG9uIGZvbGtzJyBwZXJzcGVjdGl2ZSBvbiB0aGUgYXNzdW1wdGlvbi4gDQoNCiAgICAg ICAgIi4uLkIncyBjYWxsLWJhY2sgY291bGQgaW5jbHVkZSBhIHRva2VuIHRoYXQgQSBjb3VsZCBh dHRhY2ggdG8gZnV0dXJlIElOVklURXMgdG8gQiBhcyBldmlkZW5jZSB0aGF0IHRoZSBjYWxsIHdh cyBhcHByb3ZlZCBieSBCIGFuZCB0aHVzIGF2b2lkIGJlaW5nIHNwYW0tZmlsdGVyZWQuIg0KDQog ICAgICAgIEFzc3VtaW5nIHRoZXJlIGFyZSBtYW55IG9uZS13YXkgY2FsbGluZyByZWxhdGlvbnNo aXBzIHdvdWxkIHN0b3JhZ2Uvc2VhcmNoIHJlcXVpcmVtZW50cyBmb3IgdGhlIHRva2VucyBldmVu dHVhbGx5IG91dHdlaWdoIHRoZSBiZW5lZml0Pw0KDQogICAgICAgIEJlc3QgcmVnYXJkcywNCiAg ICAgICAgUnVzcw0KDQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAg IEZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERh bGUgUi4gV29ybGV5DQogICAgICAgIFNlbnQ6IFN1bmRheSwgSnVuZSAxNCwgMjAyMCA1OjI2IFBN DQogICAgICAgIFRvOiBzaXBjb3JlQGlldGYub3JnDQogICAgICAgIFN1YmplY3Q6IFtFWFRFUk5B TF0gUmU6IFtzaXBjb3JlXSBwbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIGRyYWZ0LXBlbmFy LXNpcGNvcmUtcmF0aW5ncHJvdmlkZWQtMDANCg0KICAgICAgICBJIGRvbid0IGtub3cgb2YgdGhp cyBxdWVzdGlvbiBpcyByZWxhdGVkIHRvIHRoaXMgZHJhZnQsIGJ1dCByZWFkaW5nIGFib3V0IHRo aXMgZHJhZnQgYnJpbmdzIGl0IHRvIG1pbmQ6ICBJdCBzZWVtcyBsaWtlIGFuIGlkZWFsIHN5c3Rl bSB3b3VsZCBhbGxvdyB0aGUgcG90ZW50aWFsbHktc3BhbSBjYWxsZXIgQSB0byBwdXQgc29tZSBz b3J0IG9mIHRva2VuIGluIHRoZSBJTlZJVEUgd2hpY2ggd291bGQgYmUgcmVjb3JkZWQgd2l0aCB0 aGUgdm9pY2VtYWlsIG1lc3NhZ2UgdG8gdGhlIGNhbGxlZSBCLiAgVGhlbiBpZiBCIHdhbnRlZCB0 byBjb250YWN0IEEsIEIgY291bGQgc2VuZCBhbiBJTlZJVEUgdGhhdCBpbmNsdWRlcyB0aGUgdG9r ZW4sIHRodXMgYWxsb3dpbmcgQSB0byBwcm9jZXNzIEIncyBjYWxsIGFzIGEgY29udGludWF0aW9u IG9mIHRoZSBvcmlnaW5hbCBjYWxsLiAgU2ltaWxhcmx5LCBCJ3MgY2FsbC1iYWNrIGNvdWxkIGlu Y2x1ZGUgYSB0b2tlbiB0aGF0IEEgY291bGQgYXR0YWNoIHRvIGZ1dHVyZSBJTlZJVEVzIHRvIEIg YXMgZXZpZGVuY2UgdGhhdCB0aGUgY2FsbCB3YXMgYXBwcm92ZWQgYnkgQiBhbmQgdGh1cyBhdm9p ZCBiZWluZyBzcGFtLWZpbHRlcmVkLg0KDQogICAgICAgIERhbGUNCg0KICAgICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBzaXBjb3Jl IG1haWxpbmcgbGlzdA0KICAgICAgICBzaXBjb3JlQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8v bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpcGNvcmUmYW1wO2RhdGE9MDIl N0MwMSU3Q3J1c3NwJTQwbWljcm9zb2Z0LmNvbSU3QzcyY2RhNTU5N2M2NTRmMWEyODY3MDhkODE2 MzNiOWM1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MwJTdDMCU3QzYzNzI4 Mzc1ODY5ODc2OTc5OCZhbXA7c2RhdGE9MHdEbmpoY0wzMVFSWm1pMUd3RXdieUlyZzZxb2wxZFJS UXUycnkySm5xNCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQogICAgICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIHNpcGNvcmUgbWFpbGluZyBs aXN0DQogICAgICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lwY29yZSZhbXA7ZGF0YT0wMiU3QzAxJTdDcnVz c3AlNDBtaWNyb3NvZnQuY29tJTdDNzJjZGE1NTk3YzY1NGYxYTI4NjcwOGQ4MTYzM2I5YzUlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzAlN0MwJTdDNjM3MjgzNzU4Njk4NzY5 Nzk4JmFtcDtzZGF0YT0wd0RuamhjTDMxUVJabWkxR3dFd2J5SXJnNnFvbDFkUlJRdTJyeTJKbnE0 JTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3Jl QGlldGYub3JnDQogICAgaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc2lwY29yZSZhbXA7ZGF0YT0wMiU3QzAxJTdDcnVzc3AlNDBtaWNyb3NvZnQuY29tJTdDNzJj ZGE1NTk3YzY1NGYxYTI4NjcwOGQ4MTYzM2I5YzUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzAlN0MwJTdDNjM3MjgzNzU4Njk4NzY5Nzk4JmFtcDtzZGF0YT0wd0RuamhjTDMx UVJabWkxR3dFd2J5SXJnNnFvbDFkUlJRdTJyeTJKbnE0JTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzaXBjb3JlJmFtcDtkYXRhPTAyJTdDMDElN0NydXNzcCU0MG1p Y3Jvc29mdC5jb20lN0M3MmNkYTU1OTdjNjU0ZjFhMjg2NzA4ZDgxNjMzYjljNSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMCU3QzAlN0M2MzcyODM3NTg2OTg3Njk3OTgmYW1w O3NkYXRhPTB3RG5qaGNMMzFRUlptaTFHd0V3YnlJcmc2cW9sMWRSUlF1MnJ5MkpucTQlM0QmYW1w O3Jlc2VydmVkPTANCg== From nobody Wed Jun 24 15:50:28 2020 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 48A413A11BE for ; Wed, 24 Jun 2020 15:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 vcO-91sF-Rce for ; Wed, 24 Jun 2020 15:50:25 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2041.outbound.protection.outlook.com [40.107.244.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 8D15C3A0BD9 for ; Wed, 24 Jun 2020 15:50:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KBP04fc6ZF9vaeoHQumFBZBPb7VS1WtLjtekCicG3C7TY7B+ExZy0TT9Zh+7oLzelJzObhxS0b9sS0YsrYtyKsf4D233y8d3RN7ypugL5KYfXJqpC5DMMSuDErpDomSjPuBqbdp0vF/wBJT4HbWynbbl2rpcUlDWl3x4YxzacPIJcsnZhKlqU/yGp6NqT8IAhuw8G4py2aT85TFHCiGzYT0U/gThmYTXDhxGaj3u6S13LZ3dx1nDlOP1EUI0PhZqaqa6SWMYYrR0NjQBgdOi60MNQMLmEwrxlNNnM/lgCKo7WekhKRPi+7a5d26cSfiFahQRunbM5HaIC8PVyhuLeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+t6G6oA909+kPA/VvY/5nWQmwqoOfBERMkz05AwXCHc=; b=Fr1QdPT1rNnpYRDy5O/J1NO95PsFe39VWA9jyjXRgHCXEcMeevJB2QReaGQEp++7tRXkhrvgC9bdWNY40rnKA1oZNcBygozyl++CKCtuR0+/SInEug97vixVu/p0qqMILH01oO28Iaqf1WMW29i+P8WNRH6KoTi1awsmkis6w/dnWcI82rLSaxqH5qGVLJLuhFJH59Cos+WAsxcZQNqBvG0qEwbwav7gq7aN8rUOTmES9sDsh/35cjBkPZZy70oiNBubWnx0tgztQySXkcVrZBcuQZmQASfYW6z21ShJJP1HGe8ntOO0ucsxp/G3IC3KinXggS71zizXvkuLRsy3fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=telurix.com smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+t6G6oA909+kPA/VvY/5nWQmwqoOfBERMkz05AwXCHc=; b=RpuU3KIp3hFuKDBXbX4Q/jsJ22CTglsDI04NIYSqr1v1sv/jdDXJ6j2rcbvgmqTNBs1fxu2l23E/S2/EvJWGLQcci265mEdpzP0FU/M22l5KAYEVyu3Ca6aiy8YPy5V0juT9Wr+LqWm0SjJeZQSTi3v+9qsY8iA11lWWub2zAag= Received: from MN2PR14CA0002.namprd14.prod.outlook.com (2603:10b6:208:23e::7) by DM6PR12MB4316.namprd12.prod.outlook.com (2603:10b6:5:21a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 24 Jun 2020 22:50:24 +0000 Received: from BL2NAM02FT003.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23e:cafe::31) by MN2PR14CA0002.outlook.office365.com (2603:10b6:208:23e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 24 Jun 2020 22:50:24 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT003.mail.protection.outlook.com (10.152.76.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 24 Jun 2020 22:50:23 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05OMoLqw025932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Jun 2020 18:50:22 -0400 To: Roman Shpount , OKUMURA Shinji Cc: SIPCORE References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> From: Paul Kyzivat Message-ID: <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> Date: Wed, 24 Jun 2020 18:50:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(376002)(39860400002)(346002)(136003)(396003)(46966005)(316002)(110136005)(4326008)(36906005)(7596003)(83380400001)(8936002)(82310400002)(2906002)(70586007)(356005)(5660300002)(786003)(2616005)(956004)(31696002)(186003)(86362001)(70206006)(82740400003)(47076004)(53546011)(15650500001)(31686004)(26005)(336012)(75432002)(478600001)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89aba6d2-c66a-4356-3777-08d81890facf X-MS-TrafficTypeDiagnostic: DM6PR12MB4316: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0444EB1997 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LwfQXLi4BS7n2HfmiWy2y4DHe02pJ73IcTHXBjZqLLlLkx2LC28QJ5dma98+qYj/+U0nQHd7K3OFFme/tbuGKD0leujySbUXz0dCv0dDp1V5W8rVRbCH/ihaeqCVZPLpxySUrQ7LoAzNOTeWzyBXRVLFUDYS6WSgJASgLJiHWv8pYIJ6SbzurxtYxuCzNGVsJKJ7VdvIjeJnsD/TH5zQ47mkicq2p/X/tOriSRPXRYRsmD2ztALe/BKvF4MomR7atqKQagfecMUbdNlnWRfIfmP1BkiInn5d6GqYAESI6/xRNcs+U+7fLudJemBOhlZkbhNUOO3XyWfAYOnF4Qcns7wszRulwWbtvC6imu23v3Co1VMf+ZrD7glR7fM/rfUnp6uenZX0+1AHw9vSrucr8jWQ2dh9zOPpDN8gln/YZx3HCsMmKvDdWCHja2J9++qE X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2020 22:50:23.4546 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 89aba6d2-c66a-4356-3777-08d81890facf X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT003.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4316 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 22:50:27 -0000 ISTM that the key issue Shinji is raising is that it could be problematic to raise an error to an UPDATE that is doing a target refresh. This is true regardless of what else the UPDATE is doing - an offer, session timer refresh, or maybe nothing else. The bottom line here is that if you have an urgent need to do a target refresh, you should do it with a request that has little to no chance of being rejected. This is of course under the control of the UAC. If the UAC chooses to do a target refresh with an UPDATE, and in conjunction with a session time refresh (and/or offer) then it should be prepared for the consequences if the UPDATE is rejected (with 491 or anything else.) I guess we could discuss how much (if any) of this logic ought to be included in the document. I don't think this alters the validity of using 491 for a session timer glare situation. Thanks, Paul On 6/24/20 3:19 PM, Roman Shpount wrote: > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji > wrote: > > >> 1. Handling of UPDATE with no SDP glare > >> I'm not going to deny the solution with the 491 response, but I > think it has a big impact. > > > > The situation with session timers is different from target > refresh. Target refresh is updated for each UA independently. > Session timer is negotiated for the entire session, so more > collision scenarios are possible. One of such scenarios is both UA > sending UPDATE at the same time. If these UPDATE requests do not > carry SDP, currently they should be accepted. Resulting session > timer state is ambiguous. The only reliable way to prevent ambiguous > session timer state in this case is to refuse the UPDATE message, > similar to the session description collision. This is why 491 was > suggested. > > First of all, is a 491 rejected solution planned for bis? > > > It was discussed but nothing is final. > > If so, the UPDATE for target-refresh and the one for session-refresh > are combined, as such they affect each other. And I think the result > will be rarely ambiguous, if there is no change in the session timer > policy of each entity(UAC, proxies and UAS). Even so, should UAs > reject the UPDATE request? If the UPDATE with new remote-target-uri > is rejected, the UA will be unreachable. > > >  This should be no different than the UPDATE with SDP collision. I am > not sure what problem you are talking about. > > >> 2. Handling of UPDATE transactions during initial INVITE > >> RFC6141 says, if in doubt, send a refresh request to confirm. > > This is exactly the reason why handling of UPDATE transaction > collisions needs to be resolved. If session timer ends up in an > ambiguous state, it is likely ambiguous for both UA and both UA will > initiate an UPDATE refresh request to confirm, which will result in > a collision. > > I suggest the method in RFC3261 Section 14.1 as a procedure to avoid > collisions on retransmission. And we also need to decide how UAs > detect collisions. > > > I am not sure what you are talking about. > _____________ > Roman Shpount From nobody Thu Jun 25 11:21:28 2020 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 98FC73A0F02 for ; Thu, 25 Jun 2020 11:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 A0ZJpduZrDie for ; Thu, 25 Jun 2020 11:21:07 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 EA6213A0F15 for ; Thu, 25 Jun 2020 11:21:03 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id t6so6146088otk.9 for ; Thu, 25 Jun 2020 11:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yLLA8bQrXAznINNRV7B/OScbAte+eakfFMNKRpjD+0Q=; b=JY7Gnz/y+5rg8vHok4V6il2OAZPNA3lVcQegvUusDSa/PzUyZs4WX2KdnGtg0oihun lP/ThNOwhdFxTiRedBAb/r95ysKXuwP9QKOM3cE8VutiwQsfOhATC2gdyNvT41XryJwT x6NlIwwlXSh27PujRUHW4rGQNwCPjWTjJFNokKDlwR7qtGoq0xx3TOHPMi1uZIaCd4nz bs7qFo96OId4pNkdhL0c+SINfh+mHjTXNUVXHW5iJIibgx35w7SXDkmcpAXU+UOiZ2jX 79nH90Hbb4wmK+0EExHI7iXF/hvTGWEhvSGTp69qwaEqAVi6JOo8GJx9gEJuu7KzUORK 6NpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yLLA8bQrXAznINNRV7B/OScbAte+eakfFMNKRpjD+0Q=; b=D0XdCcYswTyipDoflG4TE4OjqoKs+LIFBZwjwBZnHSwXHbXZ7O/UrFRONnBsUUDrS3 xyZwj53wF0EQKECXKAtaPqXZh2qnXmXNkI5GcLqlXgCQ+0o2/NxUwGQKxnpONFZo61Hn 1a4UmJO+S5DHmNZVJtud7FGUp8R+zSIq/75QYrbFZU91WpHd4zOzmUZ3OeZie8qg7R4i HwWZjEWvPRiqlv1851Jr59fmceX/vBuwUPPn/XWKEnqDzgfyFIenCpTSo8tKMeTT7ZrX Py0VGqKoOOYw9c1j4DAKGiO3Om03L3L0Nza7UZlyIB+/unXKdaBPWcmPTFMLG7hoYyAP c9tg== X-Gm-Message-State: AOAM530OAQS+egs7pQXLuI5S5xb/dbiZG9gAigwkNccGV563LZOHijaM V3xm3KD+3XE44rM8NYgybTqV7oD2kGs= X-Google-Smtp-Source: ABdhPJx0vUZaehtp1HjlZSeoHFl21dPBFeQVQ7ZnfrIvqOiZwsyWF6yM4TnP60FFPbGKi4NgoZ16pg== X-Received: by 2002:a05:6830:15c3:: with SMTP id j3mr4342566otr.353.1593109262534; Thu, 25 Jun 2020 11:21:02 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id c23sm5628684otd.7.2020.06.25.11.21.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 11:21:01 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id m2so6135164otr.12 for ; Thu, 25 Jun 2020 11:21:01 -0700 (PDT) X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr26974220otr.13.1593109260597; Thu, 25 Jun 2020 11:21:00 -0700 (PDT) MIME-Version: 1.0 References: <4bb0903e-382d-7528-06fa-0f6b4111bc55@gmail.com> <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> In-Reply-To: <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> From: Roman Shpount Date: Thu, 25 Jun 2020 14:20:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: OKUMURA Shinji , SIPCORE Content-Type: multipart/alternative; boundary="00000000000090ff5c05a8eca7da" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 18:21:27 -0000 --00000000000090ff5c05a8eca7da Content-Type: text/plain; charset="UTF-8" Hi Paul, First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. Best Regards, _____________ Roman Shpount On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat wrote: > ISTM that the key issue Shinji is raising is that it could be > problematic to raise an error to an UPDATE that is doing a target > refresh. This is true regardless of what else the UPDATE is doing - an > offer, session timer refresh, or maybe nothing else. > > The bottom line here is that if you have an urgent need to do a target > refresh, you should do it with a request that has little to no chance of > being rejected. > > This is of course under the control of the UAC. If the UAC chooses to do > a target refresh with an UPDATE, and in conjunction with a session time > refresh (and/or offer) then it should be prepared for the consequences > if the UPDATE is rejected (with 491 or anything else.) > > I guess we could discuss how much (if any) of this logic ought to be > included in the document. > > I don't think this alters the validity of using 491 for a session timer > glare situation. > > Thanks, > Paul > > On 6/24/20 3:19 PM, Roman Shpount wrote: > > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji > > wrote: > > > > >> 1. Handling of UPDATE with no SDP glare > > >> I'm not going to deny the solution with the 491 response, but I > > think it has a big impact. > > > > > > The situation with session timers is different from target > > refresh. Target refresh is updated for each UA independently. > > Session timer is negotiated for the entire session, so more > > collision scenarios are possible. One of such scenarios is both UA > > sending UPDATE at the same time. If these UPDATE requests do not > > carry SDP, currently they should be accepted. Resulting session > > timer state is ambiguous. The only reliable way to prevent ambiguous > > session timer state in this case is to refuse the UPDATE message, > > similar to the session description collision. This is why 491 was > > suggested. > > > > First of all, is a 491 rejected solution planned for bis? > > > > > > It was discussed but nothing is final. > > > > If so, the UPDATE for target-refresh and the one for session-refresh > > are combined, as such they affect each other. And I think the result > > will be rarely ambiguous, if there is no change in the session timer > > policy of each entity(UAC, proxies and UAS). Even so, should UAs > > reject the UPDATE request? If the UPDATE with new remote-target-uri > > is rejected, the UA will be unreachable. > > > > > > This should be no different than the UPDATE with SDP collision. I am > > not sure what problem you are talking about. > > > > >> 2. Handling of UPDATE transactions during initial INVITE > > >> RFC6141 says, if in doubt, send a refresh request to confirm. > > > This is exactly the reason why handling of UPDATE transaction > > collisions needs to be resolved. If session timer ends up in an > > ambiguous state, it is likely ambiguous for both UA and both UA will > > initiate an UPDATE refresh request to confirm, which will result in > > a collision. > > > > I suggest the method in RFC3261 Section 14.1 as a procedure to avoid > > collisions on retransmission. And we also need to decide how UAs > > detect collisions. > > > > > > I am not sure what you are talking about. > > _____________ > > Roman Shpount > > --00000000000090ff5c05a8eca7da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

First of all, the issue with t= arget refresh that Shinjit was raising is not new. It affects session descr= iption updates as much as it does session timers.

= Second, I am not sure there is an actual problem. Target refresh is done vi= a a SIP transaction, so it does not happen instantaneously. SIP transaction= s=C2=A0can be delayed due to proxy processing or network delays, as well as= due to a packet loss. The delay introduced by 491 error response is genera= lly comparable to transaction delay, so it normally does not introduce any = new problems. All that should happen due to a 491 response, is that the tra= nsaction should be retried with some delay and target refresh should happen= slightly later.

Considering that this is an exist= ing design consideration which is not specific to SIP session timer, I do n= ot think it warrants a discussion in the session timer document.
=
Best Regards,
_____________
Ro= man Shpount


On Wed, Jun 24, 2020 at 6:50 PM Paul Kyziv= at <pkyzivat@alum.mit.edu&g= t; wrote:
ISTM t= hat the key issue Shinji is raising is that it could be
problematic to raise an error to an UPDATE that is doing a target
refresh. This is true regardless of what else the UPDATE is doing - an
offer, session timer refresh, or maybe nothing else.

The bottom line here is that if you have an urgent need to do a target
refresh, you should do it with a request that has little to no chance of being rejected.

This is of course under the control of the UAC. If the UAC chooses to do a target refresh with an UPDATE, and in conjunction with a session time refresh (and/or offer) then it should be prepared for the consequences
if the UPDATE is rejected (with 491 or anything else.)

I guess we could discuss how much (if any) of this logic ought to be
included in the document.

I don't think this alters the validity of using 491 for a session timer=
glare situation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

On 6/24/20 3:19 PM, Roman Shpount wrote:
> On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji <ietf.shinji@gmail.com
> <mailto:= ietf.shinji@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 >> 1. Handling of UPDATE with no SDP glare >=C2=A0 =C2=A0 =C2=A0 >> I'm not going to deny the solution wi= th the 491 response, but I
>=C2=A0 =C2=A0 =C2=A0think it has a big impact.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The situation with session timers is differen= t from target
>=C2=A0 =C2=A0 =C2=A0refresh. Target refresh is updated for each UA inde= pendently.
>=C2=A0 =C2=A0 =C2=A0Session timer is negotiated for the entire=C2=A0ses= sion, so more
>=C2=A0 =C2=A0 =C2=A0collision=C2=A0scenarios are possible. One of such = scenarios is both UA
>=C2=A0 =C2=A0 =C2=A0sending UPDATE at the same time. If these UPDATE=C2= =A0requests do not
>=C2=A0 =C2=A0 =C2=A0carry SDP, currently they should be accepted. Resul= ting session
>=C2=A0 =C2=A0 =C2=A0timer state is ambiguous. The only reliable way to = prevent ambiguous
>=C2=A0 =C2=A0 =C2=A0session timer state in this case is to refuse the U= PDATE message,
>=C2=A0 =C2=A0 =C2=A0similar to the session description collision. This = is why 491 was
>=C2=A0 =C2=A0 =C2=A0suggested.
>
>=C2=A0 =C2=A0 =C2=A0First of all, is a 491 rejected solution planned fo= r bis?
>
>
> It was discussed but nothing is final.
>
>=C2=A0 =C2=A0 =C2=A0If so, the UPDATE for target-refresh and the one fo= r session-refresh
>=C2=A0 =C2=A0 =C2=A0are combined, as such they affect each other. And I= think the result
>=C2=A0 =C2=A0 =C2=A0will be rarely ambiguous, if there is no change in = the session timer
>=C2=A0 =C2=A0 =C2=A0policy of each entity(UAC, proxies and UAS). Even s= o, should UAs
>=C2=A0 =C2=A0 =C2=A0reject the UPDATE request? If the UPDATE with new r= emote-target-uri
>=C2=A0 =C2=A0 =C2=A0is rejected, the UA will be unreachable.
>
>
>=C2=A0 =C2=A0This should be no different than the UPDATE with SDP colli= sion. I am
> not sure what problem you are talking about.
>
>=C2=A0 =C2=A0 =C2=A0 >> 2. Handling of UPDATE transactions during= initial INVITE
>=C2=A0 =C2=A0 =C2=A0 >> RFC6141 says, if in doubt, send a refresh= request to confirm.
>=C2=A0 =C2=A0 =C2=A0 > This is exactly the reason why handling of UP= DATE transaction
>=C2=A0 =C2=A0 =C2=A0collisions needs to be resolved. If session timer e= nds up in an
>=C2=A0 =C2=A0 =C2=A0ambiguous=C2=A0state, it is likely ambiguous for bo= th UA and both UA will
>=C2=A0 =C2=A0 =C2=A0initiate an UPDATE refresh request to confirm, whic= h will result in
>=C2=A0 =C2=A0 =C2=A0a collision.
>
>=C2=A0 =C2=A0 =C2=A0I suggest the method in RFC3261 Section 14.1 as a p= rocedure to avoid
>=C2=A0 =C2=A0 =C2=A0collisions on retransmission. And we also need to d= ecide how UAs
>=C2=A0 =C2=A0 =C2=A0detect collisions.
>
>
> I am not sure what you are talking about.
> _____________
> Roman Shpount

--00000000000090ff5c05a8eca7da-- From nobody Thu Jun 25 12:24:41 2020 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 DACDB3A0FE5 for ; Thu, 25 Jun 2020 12:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 sBJUCTeaQv9I for ; Thu, 25 Jun 2020 12:24:38 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2086.outbound.protection.outlook.com [40.107.220.86]) (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 31EA33A0F73 for ; Thu, 25 Jun 2020 12:24:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SqC6aIiBreVCGCX7v+UlJ+A2Dk0BVlr6GynXaJgCXjqQVREplcYZxlkzR3Nik9o9+XaHEyqo6FnKZlxy1ik4h+iacjm2R5Q7SsaBW1z0VnKjgvNFzV8Lir0n1SJry8oLa3gD/4I/iDl7cC1PkbskTbY56ZLMqLLoi+YW9+5dYQTyBV/rhFWWCIZAZbwpIF5Dc4gZAVIkAOnQdOwQRa3xmd4zUlhodLZJrLiP0B1ARh8B/WRbaqU06SfBs8IQEEnphfVUqbOJ7pu826Rt6q8tK8leXH8HTBBAZU9ZuEjbpvpJmXq2DPoIGnD3llhPO8z8EmhO7KHOe0bZr5UjK1sNfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lsXyTWn2VNhsF3uElbpwjV9jvRZSN3TMguEQyM/nt4U=; b=hKi9n/X+6cqBTlLhk+3ELKtKIAPvcerwXCkOaa3McgLGeIJJM8oqQ6UHvgLc/cEUwWGLOYfGbz3Re2cszM5KwauA5BAQYvk6zGfyh8SxX8xIA5zKiCPVYN1mgs9FHf3QsIXpTZU54UODyf/O6SrgkHFGNvQZwY1/Doh5BgR6p8OWboPdx1TFxynN/IGR/cxmHf9ORehtFaiKJiNtVP+SN8dpy860/QFwLTk0FIaWsUt47k4RqfNkhVNthPkJy4O3nDJuK4LJUP1lmL+p3OmDsTCCL9LBBxUaBkwXyHNdN0irNDMa7rPnq5LyvIZfBp3VYHg5wwzgI1atSWQAHajSew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=telurix.com smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lsXyTWn2VNhsF3uElbpwjV9jvRZSN3TMguEQyM/nt4U=; b=c6+zmv6GFm2l6D3k0dqLvz8c0vNQqpWuijQjr2sHAe+1NlA1baM5i8JZWNGk/lpvmL8xTSc9HInflY6WiOeOEMYMHlugt4UUEPoqQYhoRJCwGQmYgazIbyQA5TpaU+7qZRt0lsdpo1NFUhhYo2bA/DkYa+4FgDeQ8c+uNzxXJnw= Received: from DM5PR1101CA0005.namprd11.prod.outlook.com (2603:10b6:4:4c::15) by DM6PR12MB4369.namprd12.prod.outlook.com (2603:10b6:5:2a1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Thu, 25 Jun 2020 19:24:37 +0000 Received: from CY1NAM02FT056.eop-nam02.prod.protection.outlook.com (2603:10b6:4:4c:cafe::27) by DM5PR1101CA0005.outlook.office365.com (2603:10b6:4:4c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24 via Frontend Transport; Thu, 25 Jun 2020 19:24:37 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT056.mail.protection.outlook.com (10.152.74.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Thu, 25 Jun 2020 19:24:36 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05PJOXSB013201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2020 15:24:34 -0400 To: Roman Shpount Cc: OKUMURA Shinji , SIPCORE References: <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Thu, 25 Jun 2020 15:24:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(376002)(346002)(396003)(46966005)(4326008)(83380400001)(2906002)(15650500001)(8676002)(53546011)(86362001)(82310400002)(478600001)(8936002)(5660300002)(82740400003)(47076004)(31696002)(356005)(7596003)(70586007)(70206006)(6916009)(786003)(26005)(316002)(54906003)(336012)(956004)(2616005)(75432002)(31686004)(186003)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4f70c1aa-57e6-487f-c5ad-08d8193d65d6 X-MS-TrafficTypeDiagnostic: DM6PR12MB4369: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0445A82F82 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CBGaMRZc5jhoX54CglpjI+AYjDs7F5sv9P/DRwBTdpC/Q2QqojaSQ7uhDI8BnmXwg2Jmn1VtvDBl4+WpP9unWoMThlxG2VlmQzt2ovZbBqEDFdYmieEvMwCoU3uMZ05LG8TYWC6dRSrgV+ltGQExiKc8YlGTUmQAlFZEKym1LLWEr6kZ6Tvo4HfvrDN7iNQ8Ivn7HGvsZ6xGQJa2rHAuTfmxa1W9cABdvHKgDxW/UIrpH448gbYgOdMxdtukstGuadUPEUioRZU8rUDMcBoHVm7ziV9Wip52g8zhM8t27YTIqUd8WcyvYZmd6tuQHg7A4zLBgyKc4b1Xr1LZ+paBgd8YXvgU7a7yJlXSHVCRqFQBvkl9TdTdUg08mnQ/ahLH1B4SoHUpT7OYQrtQRnLQcjCckElszeHWl3USEZtoC63ihjo2ut2X8Y9sUtTGptSG X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2020 19:24:36.2450 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4f70c1aa-57e6-487f-c5ad-08d8193d65d6 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT056.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4369 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 19:24:40 -0000 Roman, On 6/25/20 2:20 PM, Roman Shpount wrote: > Hi Paul, > > First of all, the issue with target refresh that Shinjit was raising is > not new. It affects session description updates as much as it does > session timers. > > Second, I am not sure there is an actual problem. Target refresh is done > via a SIP transaction, so it does not happen instantaneously. SIP > transactions can be delayed due to proxy processing or network delays, > as well as due to a packet loss. The delay introduced by 491 error > response is generally comparable to transaction delay, so it normally > does not introduce any new problems. All that should happen due to a 491 > response, is that the transaction should be retried with some delay and > target refresh should happen slightly later. > > Considering that this is an existing design consideration which is not > specific to SIP session timer, I do not think it warrants a discussion > in the session timer document. My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. Thanks, Paul > Best Regards, > _____________ > Roman Shpount > > > On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: > > ISTM that the key issue Shinji is raising is that it could be > problematic to raise an error to an UPDATE that is doing a target > refresh. This is true regardless of what else the UPDATE is doing - an > offer, session timer refresh, or maybe nothing else. > > The bottom line here is that if you have an urgent need to do a target > refresh, you should do it with a request that has little to no > chance of > being rejected. > > This is of course under the control of the UAC. If the UAC chooses > to do > a target refresh with an UPDATE, and in conjunction with a session time > refresh (and/or offer) then it should be prepared for the consequences > if the UPDATE is rejected (with 491 or anything else.) > > I guess we could discuss how much (if any) of this logic ought to be > included in the document. > > I don't think this alters the validity of using 491 for a session timer > glare situation. > >         Thanks, >         Paul > > On 6/24/20 3:19 PM, Roman Shpount wrote: > > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji > > > >> wrote: > > > >      >> 1. Handling of UPDATE with no SDP glare > >      >> I'm not going to deny the solution with the 491 response, > but I > >     think it has a big impact. > >      > > >      > The situation with session timers is different from target > >     refresh. Target refresh is updated for each UA independently. > >     Session timer is negotiated for the entire session, so more > >     collision scenarios are possible. One of such scenarios is > both UA > >     sending UPDATE at the same time. If these UPDATE requests do not > >     carry SDP, currently they should be accepted. Resulting session > >     timer state is ambiguous. The only reliable way to prevent > ambiguous > >     session timer state in this case is to refuse the UPDATE message, > >     similar to the session description collision. This is why 491 was > >     suggested. > > > >     First of all, is a 491 rejected solution planned for bis? > > > > > > It was discussed but nothing is final. > > > >     If so, the UPDATE for target-refresh and the one for > session-refresh > >     are combined, as such they affect each other. And I think the > result > >     will be rarely ambiguous, if there is no change in the > session timer > >     policy of each entity(UAC, proxies and UAS). Even so, should UAs > >     reject the UPDATE request? If the UPDATE with new > remote-target-uri > >     is rejected, the UA will be unreachable. > > > > > >   This should be no different than the UPDATE with SDP collision. > I am > > not sure what problem you are talking about. > > > >      >> 2. Handling of UPDATE transactions during initial INVITE > >      >> RFC6141 says, if in doubt, send a refresh request to confirm. > >      > This is exactly the reason why handling of UPDATE transaction > >     collisions needs to be resolved. If session timer ends up in an > >     ambiguous state, it is likely ambiguous for both UA and both > UA will > >     initiate an UPDATE refresh request to confirm, which will > result in > >     a collision. > > > >     I suggest the method in RFC3261 Section 14.1 as a procedure > to avoid > >     collisions on retransmission. And we also need to decide how UAs > >     detect collisions. > > > > > > I am not sure what you are talking about. > > _____________ > > Roman Shpount > From Pierce.Gorman@t-mobile.com Sun Jun 21 13:47:41 2020 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 CE0BB3A087D for ; Sun, 21 Jun 2020 13:47:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=Uu0FFaFS; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=Uu0FFaFS 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 Zkw_qXdua-Ek for ; Sun, 21 Jun 2020 13:47:40 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690103.outbound.protection.outlook.com [40.107.69.103]) (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 09CA03A087B for ; Sun, 21 Jun 2020 13:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9F6WGE1ljcMZneVjTkbtCi/MAt3oailu3aIk6BKloUE=; b=Uu0FFaFSEtfJui+hvqJ8HJvF6Sf/gf8NDJS2g86OdWuoLyGiROHAU6f7xyX1v/A1cOih/qAkXVMmV10ovE9ggXGUbEMYnHnULwFQ4SVuUvZ/kFyPYJTCoLsKrMhkfmDeVTuxc3kznbN7vijLKxEW86uwjfUOqYJSDyx1b4+Zy4g= Received: from CY4PR13CA0002.namprd13.prod.outlook.com (2603:10b6:903:32::12) by BYAPR02MB4984.namprd02.prod.outlook.com (2603:10b6:a03:65::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Sun, 21 Jun 2020 20:47:38 +0000 Received: from CY1NAM02FT057.eop-nam02.prod.protection.outlook.com (2603:10b6:903:32:cafe::1d) by CY4PR13CA0002.outlook.office365.com (2603:10b6:903:32::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.11 via Frontend Transport; Sun, 21 Jun 2020 20:47:38 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 18.237.140.176) smtp.mailfrom=t-mobile.com; ietf.org; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 18.237.140.176 as permitted sender) Received: from mail.ds.dlp.protect.symantec.com (18.237.140.176) by CY1NAM02FT057.mail.protection.outlook.com (10.152.75.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Sun, 21 Jun 2020 20:47:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9F6WGE1ljcMZneVjTkbtCi/MAt3oailu3aIk6BKloUE=; b=Uu0FFaFSEtfJui+hvqJ8HJvF6Sf/gf8NDJS2g86OdWuoLyGiROHAU6f7xyX1v/A1cOih/qAkXVMmV10ovE9ggXGUbEMYnHnULwFQ4SVuUvZ/kFyPYJTCoLsKrMhkfmDeVTuxc3kznbN7vijLKxEW86uwjfUOqYJSDyx1b4+Zy4g= Received: from MN2PR22CA0024.namprd22.prod.outlook.com (2603:10b6:208:238::29) by BN7PR02MB5057.namprd02.prod.outlook.com (2603:10b6:408:22::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Sun, 21 Jun 2020 20:47:35 +0000 Received: from BL2NAM02FT055.eop-nam02.prod.protection.outlook.com (2603:10b6:208:238:cafe::b2) by MN2PR22CA0024.outlook.office365.com (2603:10b6:208:238::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Sun, 21 Jun 2020 20:47:35 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 208.54.147.100) smtp.mailfrom=t-mobile.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 208.54.147.100 as permitted sender) Received: from webmail.t-mobile.com (208.54.147.100) by BL2NAM02FT055.mail.protection.outlook.com (10.152.77.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.3109.22 via Frontend Transport; Sun, 21 Jun 2020 20:47:35 +0000 Received: from PRDPWEXCH003D.gsm1900.org (10.92.82.32) by PRDMSEXCH004.gsm1900.org (10.154.50.224) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 21 Jun 2020 13:47:34 -0700 Received: from prdpwexch0054.gsm1900.org (10.13.44.113) by PRDPWEXCH003D.gsm1900.org (10.92.82.32) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 21 Jun 2020 13:47:34 -0700 Received: from plsapdm1.corp.sprint.com (144.230.172.36) by prdpwexch0054.gsm1900.org (10.13.44.113) with Microsoft SMTP Server id 15.1.1913.5; Sun, 21 Jun 2020 13:47:33 -0700 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.42/8.16.0.42) with SMTP id 05LKhRS3001472; Sun, 21 Jun 2020 15:47:33 -0500 Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by plsapdm1.corp.sprint.com with ESMTP id 31sg3a83aw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jun 2020 15:47:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AdzcYalEOQYY7WCETS/rLXD92E29iVA9HTu7irCTVaMJAOrjox0CU31KQRtN3WO63aD4qh9HKRAlilNinKAiPdwTGIckfbdZbD9gfs0JFE4u2i+WhwjD5m+VGzi7nlUMDbuWi1FtexsWqOq4jPAhRRUbub/K0b0WCHsmvGZ07B9ODQT1/0iXm2TG+HXICpxhgO8dKkxnrIRB7UjGKXl0SXC0qlcbewMu15uyhB0CjZOxBEzabqkG0eCQRN8RgCH9/ouqERO2ms3w/C3jiHYo2JV5mHQC8OVZzC/h6wCQOhDICGRDKkZ+LFCdVP0+ofQDDxIq5Zy1t9yfL5i+HugvOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9F6WGE1ljcMZneVjTkbtCi/MAt3oailu3aIk6BKloUE=; b=cVKJQgMhThTGB6f1oJf60vDesw4dfkb4GsOLgO1gswCa6dUaw2fxkkixWsU1ckxgxIP68HKvHJ0c7oUCa5Im0F9xd9qrKEBZz/zFV2RyjP8DlLTmtrF4Ztw8/yvza81y2s6scI5ADiw9XDuS4L+7BxfhJMQsAZ9KPhVrXyx6su3tGpe9dcthokBrl42ffMaeUKdr9RVU15JkxGQyJhUbC+Vv34sP1NWcNzf25NDZDEjspS0pRLFOvT8VyEcZMPmJRk4+16oLk4i2vGI+8raZ1qQlv7tmx2tgw7KDOG3oHkhBbYyiRJW/8knMTmVszzkzpsSXOsEWptnTzDyc17G6Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sprint.com; dmarc=pass action=none header.from=sprint.com; dkim=pass header.d=sprint.com; arc=none Received: from DM5PR05MB3289.namprd05.prod.outlook.com (2603:10b6:4:43::22) by DM6PR05MB7082.namprd05.prod.outlook.com (2603:10b6:5:1da::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.10; Sun, 21 Jun 2020 20:47:13 +0000 Received: from DM5PR05MB3289.namprd05.prod.outlook.com ([fe80::3891:4b85:3ab5:40b6]) by DM5PR05MB3289.namprd05.prod.outlook.com ([fe80::3891:4b85:3ab5:40b6%5]) with mapi id 15.20.3131.009; Sun, 21 Jun 2020 20:47:13 +0000 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Russ Penar , "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AQHWSAcDn4PMvWE9NEiz2dpe64oVoajjhiMw Date: Sun, 21 Jun 2020 20:47:13 +0000 Message-ID: References: <5D3B2CCC-4801-4DB8-89A4-D29ED628669D@shockey.us> In-Reply-To: <5D3B2CCC-4801-4DB8-89A4-D29ED628669D@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: shockey.us; dkim=none (message not signed) header.d=none;shockey.us; dmarc=none action=none header.from=sprint.com; x-originating-ip: [2605:a601:adf1:2b00:1d13:50ff:83c9:93b7] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8bd77992-6227-4dcd-1c49-08d816245551 x-ms-traffictypediagnostic: DM6PR05MB7082:|BN7PR02MB5057:|BYAPR02MB4984: X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;OLM:10000; x-forefront-prvs: 04410E544A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 15RhJqH7pc19lMVcUqlGoQFUcncD9e4I8g0hWZwOftCgRUUeLetg9JEpSdcE5TcV0xZLtcemzurrJcJSWGVgRGuAdh7mLTAZ0AbxhTl+EVyyR7KojdQnNNS4/OxJw51s7+uur/o6zvoazvZAZI5eieulTp1pdvfift627bRYkUTOM24Skaw6OLblndoSp0a/7kZF0rD5uGfqK6ekCVBU5pySzz8oX87dPYz6NkuGHH+lXYllsvSD8AXCQp40qb5EHfqDhdrrPfk+GyaMgoTyY/wpHGQEmXHnqPRgznm38vZ0dOnj+J+NiR8/5G1msG+2Qs+l5lWVsRpvLt0fOd2WcXzwa8Znz4jcGGNe0jg5axvY/MzRYyxOT8Q3qNTURJr4lEGFTR7gNTQDXilhQxzU2A== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3289.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(9686003)(66476007)(6506007)(86362001)(5660300002)(64756008)(8676002)(66446008)(8936002)(66946007)(186003)(66556008)(7696005)(2906002)(55016002)(76116006)(77540400001)(110136005)(16799955002)(83380400001)(71200400001)(53546011)(52536014)(33656002)(316002)(966005)(45080400002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: SOUEbRlLoMj1skuFJvEo3z85l4zGrdzPfF/ectYs2RScjOuHzLR5iVyrqW7G1orcihJPQt5hU5K0Ws1alqd5sPdlG0XHkrzG2UPuYOTRkWW8b+HJiB/MjlORwYXKU4sX6mti7mdPWYZVQNRZWT0WRk8PazS6KP1DGyMZ0ozs0OG/QPy1ERGXAgbnF07y+wTHAMUAVQl6IVSu4bszeD6mhiImiMpXRPmodqkgC8s2MN0h+x3vaRL3YsVdfJhFX+BF7MnkC5nYxtQWJicX/isKcxYr2/VegoEWGJOwzqJZNtE0U+9MBerZlaU7EMPq9n4MJMQgfCQ2VVlHPuRURLc5l3tUc1s5Cs87WvNW8lO+vAV6yhEumeBRJaOJum7H0QKO3kwf9V61L7/Pm+sf31wkBmJd+xF8i/1anoski6+CRI5GI+UYjg07TxQh22wPKDwwawpoCTT2OI5kIyR9Xe2Ik3qQ8qzJZdzm1P6uo733EtfAfUdHwhw/P4YtH910R3QU6q4M/lvIiKn2cDAG26F+2Hh+ATAutTHRaDIpTC0Llr2NGYLILMzOBVXJtvoau97U x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB7082 X-EOPAttributedMessage: 1 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BL2NAM02FT055.eop-nam02.prod.protection.outlook.com X-Forefront-Antispam-Report-Untrusted: CIP:208.54.147.100; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:webmail.t-mobile.com; PTR:InfoDomainNonexistent; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(136003)(346002)(46966005)(186003)(8676002)(26005)(70586007)(336012)(5660300002)(2906002)(70206006)(86362001)(52536014)(77540400001)(83380400001)(16799955002)(81166007)(82310400002)(966005)(6506007)(53546011)(45080400002)(33656002)(478600001)(8936002)(7696005)(316002)(47076004)(356005)(82740400003)(55016002)(110136005)(9686003); DIR:OUT; SFP:1102; X-MS-Office365-Filtering-Correlation-Id-Prvs: af0dc7d4-8afa-467a-a38b-08d8162446e4 X-Forefront-PRVS: 04410E544A X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: iBDuwKYL8c5oVFt4SSwpS8tRvKjz8NszwxTmRuJrPV3OEn3UPmoquepac6XACbc92SmBCP4I2QA1YtLaFxyOVQCi3Zx4w0tFgZ778N0S1nLlERQWRx195ByTP1XLzbYvtfTc4zzHnWYGqbbP5SOo1wlyRAhFVGQepo8YUPJQgL1+5NfhPWqJaeZJYAdHVSCi7xtGAhMwzjco177tPamRYWk932t3GY+Ddf4fKEPXQkNOPXHVkgVx4t7rGIVcUt4wcXJ7k6iIxS8fz2kZWuy3S/CfJIJATRBz5iBZjUFud0uvsSrcT95To/fVEO5yv7dZbSdLODlvOQ15cRWrVAQwo+0N1mVJRzKZMJBTeToFKCeF8lBfS/BmtNYDtsX5WOZhTLfhB1BJtRgHLKMP0edeK0Nu1+SSZokZOScf7NcH3WdyQ95FxfcyGgRgCSmIS0BoOL6ymh0XRzBdV3W+4XQrlU1abireHOixjBwafCGgR70= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR02MB5057 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CY1NAM02FT057.eop-nam02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:18.237.140.176; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:p01a.mail.dlp.protect.symantec.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(346002)(376002)(46966005)(8936002)(5660300002)(8676002)(86362001)(110136005)(2906002)(36906005)(70586007)(70206006)(82310400002)(83380400001)(316002)(336012)(33656002)(82740400003)(7636003)(77540400001)(16799955002)(186003)(55016002)(47076004)(966005)(6506007)(9686003)(52536014)(45080400002)(7696005)(26005)(478600001)(53546011); DIR:OUT; SFP:1102; X-MS-Office365-Filtering-Correlation-Id-Prvs: b8488fa1-349f-4ccf-8d45-08d816245402 X-Forefront-PRVS: 04410E544A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5ZPTu4Tf+zrCbXg3GaAVQRjeHLqtMPAQoae5+dlJsE4WtgrTKhSpnhgmPEdxQXPdErMFWndQz+LtntA+vB4nBPR1mY4N8bdfCHyQ4chyv+ZT5PieKAknCblLQ253EUPPb91mMfj9G8gcsO7s1veC5rpwdvHDtO/NRpZZkYLZQ2b8TiwcxIulIAUEQq0Es+0K3aREjPmsyvYH1jgOeIlVIIEaJUkUMJOudg+/U1D8BdNdR/tsBNqauXLyUqUC7Z1kdfHGgDoraJ9KLNn0mt4YXS/ZKNRiL7XaDrqQMeJaWcHpbgohgYLqJ/M+yQuej+3/zRXCv6PgIQrCtJE1nmbCFDt9E+F4pOGQnSeCsRud1/qHlrdQmqVCJyFH+7wROhoniLi9bCXLm8wVF0HnKov0N9dmQOQr73/MLsLs/G9u1PIdcF88dPBZr5rF4UbyuzFRluZAtCvEzW6/CA0ms1LtBsDIjNGoA8rq2rtbMrcTkBI= X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2020 20:47:37.5528 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8bd77992-6227-4dcd-1c49-08d816245551 X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[18.237.140.176]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4984 Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2020 08:41:20 -0700 Subject: Re: [sipcore] [EXTERNAL] Re: please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 21:06:09 -0000 TWUgdG9vIQ0KDQpFbmQgZW50aXRpZXMgZXhjaGFuZ2luZyBpbmZvcm1hdGlvbiBlbGVtZW50cyB0 aGF0IGNvdWxkIGJlIHVzZWQgdG8gYXV0aGVudGljYXRlIGFuZCBhdXRob3JpemUgYSBjb21tdW5p Y2F0aW9ucyBhdHRlbXB0IHNvdW5kcyBnb29kIHRvIG1lLiAgV2UgbmVlZCBhIGNhdGNoeSBhY3Jv bnltLiAgSSdsbCB2b2x1bnRlZXIgU0lHTkVULg0KDQpIbW1tLCBvbiBzZWNvbmQgdGhvdWdodCwg c2luY2UgaXQncyBiYXNlZCBvbiBTSVAsIG1heWJlIHdlIHNob3VsZCB1c2UgQ1JFQU07IENvbW11 bmljYXRpb25zIFJlbGF0aW9uc2hpcCBFeHRlbnNpYmxlIEFkZHJlc3MgTWV0aG9kLg0KDQpodHRw czovL2FjY2Vzcy5hdGlzLm9yZy9hcHBzL2dyb3VwX3B1YmxpYy9kb2N1bWVudC5waHA/ZG9jdW1l bnRfaWQ9NDMyOTUgICBTZWUgc2xpZGUgIzguDQoNClBpZXJjZQ0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBSaWNoYXJkIFNob2NrZXkNClNlbnQ6IFN1bmRheSwgSnVuZSAyMSwgMjAyMCAz OjAzIFBNDQpUbzogUnVzcyBQZW5hciA8cnVzc3A9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPjsgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlhZG5lLmNvbT47IHNpcGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gW0VYVEVSTkFMXSBSZTogcGxlYXNlIHJldmlldyBh bmQgY29tbWVudCBvbiBkcmFmdC1wZW5hci1zaXBjb3JlLXJhdGluZ3Byb3ZpZGVkLTAwDQoNCg0K SSByZWFsbHkgbGlrZSB0aGlzIGlkZWEgYXMgd2VsbC4gDQoNCuKAlCANClJpY2hhcmQgU2hvY2tl eQ0KDQpTaG9ja2V5IENvbnN1bHRpbmcgTExDDQoNCkNoYWlybWFuIG9mIHRoZSBCb2FyZCBTSVAg Rm9ydW0NCg0KaHR0cHM6Ly9uYW0wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM0ElMkYlMkZ3d3cuc2hvY2tleS51cyUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDcGll cmNlLmdvcm1hbiU0MHNwcmludC5jb20lN0NmNzQ4NmI5YWZkZDA0NDlkMzllYjA4ZDgxNjFlMjUx NCU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2MzcyODM2NjYw MTc1ODc5ODImYW1wO3NkYXRhPThqdTV6VklHU0NKQWtTNXlFQXklMkI4dmJ3QlA1b0xQdU5xMWhh SHdJUTFwUSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpodHRwczovL25hbTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy5zaXBmb3J1bS5vcmclMkYm YW1wO2RhdGE9MDIlN0MwMSU3Q3BpZXJjZS5nb3JtYW4lNDBzcHJpbnQuY29tJTdDZjc0ODZiOWFm ZGQwNDQ5ZDM5ZWIwOGQ4MTYxZTI1MTQlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFk ZiU3QzAlN0MwJTdDNjM3MjgzNjY2MDE3NTg3OTgyJmFtcDtzZGF0YT1PVHhHc1ZEazl1YTNmeWFQ eTV5OHQlMkZ5OGxHbFdsSjhGdHh5b1hkTmlMYkklM0QmYW1wO3Jlc2VydmVkPTANCg0KcmljaGFy ZDxhdD5zaG9ja2V5LnVzDQoNClNreXBlLUxpbmtlZGluLUZhY2Vib29rIOKAk1R3aXR0ZXIgIHJz aG9ja2V5MTAxDQoNClBTVE4gKzEgNzAzLTU5My0yNjgzDQoNCiANCg0K77u/T24gNi8xNi8yMCwg Nzo1MSBQTSwgInNpcGNvcmUgb24gYmVoYWxmIG9mIFJ1c3MgUGVuYXIiIDxzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJ1c3NwPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRm Lm9yZz4gd3JvdGU6DQoNCiAgICBUaGF0IGlzIGFuIGludGVyZXN0aW5nIGlkZWEgRGFsZSB0aGFu ayB5b3UsICANCg0KICAgIFRoZSBzcGlyaXQgb2YgbXkgcHJvcG9zYWwgaXMgc29tZXRoaW5nIHRv IGhlbHAgb3V0IHNwZWNpZmljYWxseSBpbiB0aGUgY3VycmVudCBjYWxsIGFuYWx5dGljcyBlbnZp cm9ubWVudCwgYW5kIGlzIGhvcGVmdWxseSBsaWdodHdlaWdodCB0byBpbXBsZW1lbnQuICBUaGF0 IHNhaWQsIGFzIEkgcmVhZCB0aHJvdWdoIHlvdXIgZW1haWwgYSBjb3VwbGUgcXVlc3Rpb25zIGNh bWUgdG8gbWluZC4NCg0KICAgICIuLiB0b2tlbiBpbiB0aGUgSU5WSVRFIHdoaWNoIHdvdWxkIGJl IHJlY29yZGVkIHdpdGggdGhlIHZvaWNlbWFpbCBtZXNzYWdlIHRvIHRoZSBjYWxsZWUgQi4iDQoN CiAgICBTaG91bGQgdGhlcmUgYmUgYW55IGFzc3VtcHRpb24gYWJvdXQgdW5hbnN3ZXJlZCBjYWxs cyAnYWx3YXlzJyBnb2luZyB0byB2b2ljZW1haWw/ICBQZXJoYXBzIGl0cyBhbiBleGNlcHRpb24g Y2FzZSwgYnV0IGN1cmlvdXMgb24gZm9sa3MnIHBlcnNwZWN0aXZlIG9uIHRoZSBhc3N1bXB0aW9u LiANCg0KICAgICIuLi5CJ3MgY2FsbC1iYWNrIGNvdWxkIGluY2x1ZGUgYSB0b2tlbiB0aGF0IEEg Y291bGQgYXR0YWNoIHRvIGZ1dHVyZSBJTlZJVEVzIHRvIEIgYXMgZXZpZGVuY2UgdGhhdCB0aGUg Y2FsbCB3YXMgYXBwcm92ZWQgYnkgQiBhbmQgdGh1cyBhdm9pZCBiZWluZyBzcGFtLWZpbHRlcmVk LiINCg0KICAgIEFzc3VtaW5nIHRoZXJlIGFyZSBtYW55IG9uZS13YXkgY2FsbGluZyByZWxhdGlv bnNoaXBzIHdvdWxkIHN0b3JhZ2Uvc2VhcmNoIHJlcXVpcmVtZW50cyBmb3IgdGhlIHRva2VucyBl dmVudHVhbGx5IG91dHdlaWdoIHRoZSBiZW5lZml0Pw0KDQogICAgQmVzdCByZWdhcmRzLA0KICAg IFJ1c3MNCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogc2lwY29y ZSA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGFsZSBSLiBXb3JsZXkN CiAgICBTZW50OiBTdW5kYXksIEp1bmUgMTQsIDIwMjAgNToyNiBQTQ0KICAgIFRvOiBzaXBjb3Jl QGlldGYub3JnDQogICAgU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW3NpcGNvcmVdIHBsZWFzZSBy ZXZpZXcgYW5kIGNvbW1lbnQgb24gZHJhZnQtcGVuYXItc2lwY29yZS1yYXRpbmdwcm92aWRlZC0w MA0KDQogICAgSSBkb24ndCBrbm93IG9mIHRoaXMgcXVlc3Rpb24gaXMgcmVsYXRlZCB0byB0aGlz IGRyYWZ0LCBidXQgcmVhZGluZyBhYm91dCB0aGlzIGRyYWZ0IGJyaW5ncyBpdCB0byBtaW5kOiAg SXQgc2VlbXMgbGlrZSBhbiBpZGVhbCBzeXN0ZW0gd291bGQgYWxsb3cgdGhlIHBvdGVudGlhbGx5 LXNwYW0gY2FsbGVyIEEgdG8gcHV0IHNvbWUgc29ydCBvZiB0b2tlbiBpbiB0aGUgSU5WSVRFIHdo aWNoIHdvdWxkIGJlIHJlY29yZGVkIHdpdGggdGhlIHZvaWNlbWFpbCBtZXNzYWdlIHRvIHRoZSBj YWxsZWUgQi4gIFRoZW4gaWYgQiB3YW50ZWQgdG8gY29udGFjdCBBLCBCIGNvdWxkIHNlbmQgYW4g SU5WSVRFIHRoYXQgaW5jbHVkZXMgdGhlIHRva2VuLCB0aHVzIGFsbG93aW5nIEEgdG8gcHJvY2Vz cyBCJ3MgY2FsbCBhcyBhIGNvbnRpbnVhdGlvbiBvZiB0aGUgb3JpZ2luYWwgY2FsbC4gIFNpbWls YXJseSwgQidzIGNhbGwtYmFjayBjb3VsZCBpbmNsdWRlIGEgdG9rZW4gdGhhdCBBIGNvdWxkIGF0 dGFjaCB0byBmdXR1cmUgSU5WSVRFcyB0byBCIGFzIGV2aWRlbmNlIHRoYXQgdGhlIGNhbGwgd2Fz IGFwcHJvdmVkIGJ5IEIgYW5kIHRodXMgYXZvaWQgYmVpbmcgc3BhbS1maWx0ZXJlZC4NCg0KICAg IERhbGUNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3JlQGlldGYub3JnDQogICAg aHR0cHM6Ly9uYW0wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lwY29yZSZhbXA7 ZGF0YT0wMiU3QzAxJTdDcGllcmNlLmdvcm1hbiU0MHNwcmludC5jb20lN0NmNzQ4NmI5YWZkZDA0 NDlkMzllYjA4ZDgxNjFlMjUxNCU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdD MCU3QzAlN0M2MzcyODM2NjYwMTc1ODc5ODImYW1wO3NkYXRhPUJwWmxoJTJGYUs1WjRpeFo5czBr azkxaEw3MUolMkZDcFlnJTJCQ3VYRThVUTJnU2slM0QmYW1wO3Jlc2VydmVkPTANCg0KICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2lwY29y ZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly9uYW0wMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lwY29yZSZhbXA7ZGF0YT0wMiU3QzAxJTdD cGllcmNlLmdvcm1hbiU0MHNwcmludC5jb20lN0NmNzQ4NmI5YWZkZDA0NDlkMzllYjA4ZDgxNjFl MjUxNCU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2MzcyODM2 NjYwMTc1ODc5ODImYW1wO3NkYXRhPUJwWmxoJTJGYUs1WjRpeFo5czBrazkxaEw3MUolMkZDcFln JTJCQ3VYRThVUTJnU2slM0QmYW1wO3Jlc2VydmVkPTANCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vbmFtMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNpcGNvcmUmYW1wO2RhdGE9MDIlN0MwMSU3Q3BpZXJjZS5nb3JtYW4lNDBzcHJpbnQuY29tJTdD Zjc0ODZiOWFmZGQwNDQ5ZDM5ZWIwOGQ4MTYxZTI1MTQlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFi MzEzMDFkOWFkZiU3QzAlN0MwJTdDNjM3MjgzNjY2MDE3NTg3OTgyJmFtcDtzZGF0YT1CcFpsaCUy RmFLNVo0aXhaOXMwa2s5MWhMNzFKJTJGQ3BZZyUyQkN1WEU4VVEyZ1NrJTNEJmFtcDtyZXNlcnZl ZD0wDQo= From nobody Fri Jun 26 22:41:44 2020 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 ABF133A0D44 for ; Fri, 26 Jun 2020 22:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 G-H5gIljyWYX for ; Fri, 26 Jun 2020 22:41:40 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2058.outbound.protection.outlook.com [40.107.21.58]) (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 E49D23A0D45 for ; Fri, 26 Jun 2020 22:41:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WtvizIu0DtHSqECrbWHN7EHxZ4VZuD9J5m7+dNf6HqcN6FACaxDg7MuHHu6qLV0Sh7FZr2e3S8CP6bePv7KiD2AHUw5Gh3WpFIrjmSVVSCmUGM6crNPR/+0/h/KC6RX345Se7Fpqsxb3yUn53fTLAUhxkW+fx44aeimEPJXhdWLr64MFC5ESBxSmwTQR97QLalFIdpCPuLSKQATvvuVtI0eimmtOCRzjD0HqhO5RxC3FraovzwfZ3K/Uip4JTO1wxwp0HquTU1Fb3BQN6TiQOyNRNBZssENUvcUcUA8oJzYMgRjKN6SNG5+YARoEBGvfG4D+pv+r2VuPxArjASY38A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b7r+Vxh+8nAO13aOdACsnXR8vhKmVXIdCjicyjNeLBs=; b=BGtSOii4BmIk6t9gy5eXNpM2PxGajG6EdE5TsypqClvOwMSmD+zQ6mTSivTRru3yWttlS0UB97wyJJTulbeCBbhUtEPPZQ1lSnrF4MbG6pPJy9dlkMzTT5E7X6Rrug2IwYoAB7rUTcQpWZJcfjmRjV5nLkVs4RH6ovh0sdmBv/DMCD/IWurzroTlJ47a53yPkCCrT5NV0RMnkf5/l3mFcJhBe2uBeBh0OXl05ZssReqbk5aUEUpsLFL5rUO6sE9oJF1YYLsLHYpdSQVvMPPD5a/t1bnxcB+jWRn58lFZiaFN/VmA5mABzAFwBFFHFe4jBq+UcMZVzyzCYC0w2TjzWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b7r+Vxh+8nAO13aOdACsnXR8vhKmVXIdCjicyjNeLBs=; b=jlQFsBMePDkyDB47ZWhueHqkWk2RnoaGITy2rrs1TR5q7oaVmStqy5hfWCvcSgl3FrG1wh5tRWxMdND42k0iOtjcsUYPCN6CNHdXxm1S/A2DOBy+zP8rwzCKDZK9p2v0qYazo1OPMlDiV57Lej12zD7UbHeUC9ne5OBFJO5FmZw= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6865.eurprd07.prod.outlook.com (2603:10a6:20b:1b4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.13; Sat, 27 Jun 2020 05:41:37 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3153.012; Sat, 27 Jun 2020 05:41:37 +0000 From: Christer Holmberg To: Russ Penar , "sipcore@ietf.org" Thread-Topic: please review and comment on draft-penar-sipcore-ratingprovided-00 Thread-Index: AdZBFbmIYErjvgZESFeR9rthnkycuwB2qu6gAAiOOoACTK5aQA== Date: Sat, 27 Jun 2020 05:41:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a6de2e19-785d-403b-9c7e-00006df9e7a1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T21:51:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87af8490-cd1a-4624-2854-08d81a5cc261 x-ms-traffictypediagnostic: AM7PR07MB6865: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0447DB1C71 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FXNz97b6CCdL7A2P6IPWXA8V4y+Yw9YAYhno2PttNdITjgIdsDQeg57OMUMKthvD0Fon8GED51v7FJqgD4O8LDBSzG+8BhLdo4pWYNz7PFgwMYPH/a9/fwhN5+aBVp+5wbNcJIbjCz1J5v7ytIEbMF1FnGfELL3WdBM2cc9/MwjzEIslpvP7DkJdiSHLDB6a9kdMgZU6fLNVrIrly8bWDptnHr7V1EL8wviHGRmzsmkL6OjLZ17UVJxRIKuMYK1ezHsqVnEfDES6NiiSdbSm1iXBI5/xFkhj0VKh7XpTu6+aArWaBoxf2Hii6/g/hEFAbwg3lgHFebZVaMihEZ1uq7yLjIROdu6QsQ8mWRkmf6SpkxHNp5x6sQhHv5zUjJlOCOI9VaIdVlH9dCouDhTK4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(52536014)(966005)(86362001)(26005)(66446008)(8936002)(110136005)(66476007)(66556008)(66946007)(77540400001)(8676002)(76116006)(64756008)(45080400002)(478600001)(316002)(33656002)(166002)(55016002)(66574015)(83380400001)(9686003)(71200400001)(6506007)(186003)(7696005)(2906002)(5660300002)(53546011)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zgHq5IR14GDNMNauxXMepSS6gLk77E0WjfuzA1W8sj4RMplq6rcHnjzy/3YIcjFO7AdhJcihHh4NysV6O1owFGnAz/RbK9H9V4236qbYT9P8qhSw59rbF1BhBy0lUidI9Ewj2BZEKJikwFQ7gc8Db/xE5FQy/kK3JmXChN+xTEJG+zsEmImj4j+10cvqszlB5HtJ/DORkA+Gn01vPu273yGiRtWi7OZ4h31mJdpW1bPtsMpKdcMdUcwjSd8t1e9m50gi/3RpySUIXDvhBgEWkzdXvPP1gKlrI7a/kX4t3CFouOgEQigW09E8ituoXH6fA+zQFocrwVajf8DZbQj6u1HU/QiGxuSRCJkaVK48tbeI3URhP9F/vecEYRXfKLB46nxsRwi3Rqo1SzF+hNEfmZ+9pwjych04KkJyD2yOdtvekIbfpFuop1l8bdefnX4BY1x6y803rGQwAqjMY8nosvVDprmRBccPyfvgpAqA6eoSlyTlTVJtaNHSbLmsAIJB x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB7012A0C45F6DFDF14D65830293900AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB7012.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87af8490-cd1a-4624-2854-08d81a5cc261 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2020 05:41:37.2151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZmMnIOlUL4ZIhsMHlyYHrdPbes0GnoDHVY4YG4WtnVys9wq5iESGZolBaVFsNDBGnVu8U4s/dUj7770tLQCckVq/3sQ9Abdb3+RyQN8yFv0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6865 Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 05:41:43 -0000 --_000_AM7PR07MB7012A0C45F6DFDF14D65830293900AM7PR07MB7012eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >I'm reconsidering the announcement idea, I'm not sure it makes sense outsi= de of a failure context. >Given there's no failure, caller either gets no answer and cancels the req= uest or reaches voicemail/announcement. > >What do you think? Something like that, I guess. The called party proxy can choose to do whatever with a call that has been = "badly rated", including forwarding it to an announcement server. Regards, Christer From: Christer Holmberg > Sent: Monday, June 15, 2020 1:41 AM To: Russ Penar >; sipcore@i= etf.org Subject: [EXTERNAL] RE: please review and comment on draft-penar-sipcore-ra= tingprovided-00 Hi, If needed, why can't the called party proxy forward the call to an announce= ment server, instead of relying on the fact that there is an SBC somewhere = that supports the mechanism and is able to play the announcement? Regards, Christer From: sipcore > O= n Behalf Of Russ Penar Sent: lauantai 13. kes=E4kuuta 2020 3.02 To: sipcore@ietf.org Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingp= rovided-00 Based on early feedback, I updated the name and proposed code number. Please review the newly named draft, I welcome everyone's perspective, than= k you! https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ From: Russ Penar Sent: Friday, June 12, 2020 2:55 PM To: 'sipcore@ietf.org' > Subject: please review and comment on draft-penar-ietf-sipcore Hi All, Please take a look at my proposed draft regarding a 1xx message letting cal= ler know their call is rated poorly/ambiguously. One early feedback is 184 may be too close to progress messages associated = with ringback, and I'd love to get more perspectives. https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ Best regards, Russ --_000_AM7PR07MB7012A0C45F6DFDF14D65830293900AM7PR07MB7012eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

>I’m reconsidering the= announcement idea, I’m not sure it makes sense outside of a failure = context.

>Given there’s no fail= ure, caller either gets no answer and cancels the request or reaches voicem= ail/announcement.

> 

>What do you think?

 

Something like that, I guess.

 

The called party proxy can choo= se to do whatever with a call that has been “badly rated”, incl= uding forwarding it to an announcement server.

 

Regards,

 

Christer

 

 

From: Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.o= rg>
Sent: Monday, June 15, 2020 1:41 AM
To: Russ Penar <russp@micr= osoft.com>; sipcore@ietf.org
Subject: [EXTERNAL] RE: please review and comment on draft-penar-sip= core-ratingprovided-00

 

Hi,

 

If needed, why can’t the = called party proxy forward the call to an announcement server, instead of r= elying on the fact that there is an SBC somewhere that supports the mechani= sm and is able to play the announcement?

 

Regards,

 

Christer

 

From: sipcore <sipcore= -bounces@ietf.org> On Behalf Of Russ Penar
Sent: lauantai 13. kes=E4kuuta 2020 3.02
To: sipcore@ietf.org
Subject: [sipcore] please review and comment on draft-penar-sipcore-= ratingprovided-00

 

Based on early feedback, I upda= ted the name and proposed code number.

Please review the newly named d= raft, I welcome everyone’s perspective, thank you!

 

https://datatr= acker.ietf.org/doc/draft-penar-sipcore-ratingprovided/

 

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: 'sipcore@ietf.org' <sipco= re@ietf.org>
Subject: please review and comment on draft-penar-ietf-sipcore<= /o:p>

 

Hi All,

Please ta= ke a look at my proposed draft regarding a 1xx message letting caller know = their call is rated poorly/ambiguously.

One early= feedback is 184 may be too close to progress messages associated with ring= back, and I’d love to get more perspectives.

https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/

Best regards,=

Russ

--_000_AM7PR07MB7012A0C45F6DFDF14D65830293900AM7PR07MB7012eurp_-- From nobody Fri Jun 26 23:10:40 2020 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 9D8C63A0D82 for ; Fri, 26 Jun 2020 23:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 a69VMytgT-Sc for ; Fri, 26 Jun 2020 23:10:37 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30073.outbound.protection.outlook.com [40.107.3.73]) (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 68BF53A0D7E for ; Fri, 26 Jun 2020 23:10:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ac08mcp1BCB4E5QnfUCUSJztWbHWlPIL9ca2t2OYHrWJhL5Osjv2xqtGr98KoMfwFcrfG2vAkMgf9dLM/h2klkgsVCoSsMYXPHOZdNySKT+/g4yn36Cn84IIj4RffriVd8ZUNCfarRJ/Xm6EKHDgSfdeSAgbKw0Nt5AspTJ/mOTOmzHTDiIwfRqXuDbk/97QC8oyflnYHBWzDD2+vP1XyvV34pi55LFmR7MmVZiVUJhVAKgmaq7/JNuiGMPo5cJA/qrPlCjJkWeZhnxOWX60EIPfCJ5bheu0hW+L94L7WeRCR4561OeE7sqJgEIIF2kTajByJSCxTh31i+T1Uo6EqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SoMWp9IWi/KndYLNdhKfGLYbEcX/2/GNjJBGwN4Cvxw=; b=D8US1Bd0qrGlW+YP/3xMCcMk72qlWOhtn1rcIFLBn16tUAqcDaTQmZtwoCA83ctCTDdT+WFOcdngFjKk26PG+7UkoqiV8tuf1tk+sMyQwv7Sj5gReUaoxvGw694D5Db8V2rU9MnztoqzmJkPNzoLsfN4CGKoGDEW8z7xzoTZvA7urOr+KIgL3ckuyGyCdTd1POJR4nj1bhsg3cWI2ng14HCgGZRTa3AjGYzh1dEOgS+qRHCBIGjKrmk5wEo0jiFo+SHXb6NvaWwhDJ/iVhXIh8fXLYH1VdOVaTJ+EjzqMkk/+hYo7DQkzvp6+68DhjBS7XBVKwnT+L/2EFPXSAhKzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SoMWp9IWi/KndYLNdhKfGLYbEcX/2/GNjJBGwN4Cvxw=; b=pBMflxVyy8urkmzNEOF5VFUQIt7LG/cyPqlk8IB0QMf6RfxrJL7IO9i6ihqhAh/IJgjYq5G+nFpwjfP+xkV0llii+uqkXBYSN1kmiEkiRhv4PqywAhbz2oKnAa5l9ovjeRnPXLXUCSpnB6LfN7zzJtLhVLqNWurwQDHvWoEjrUM= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6529.eurprd07.prod.outlook.com (2603:10a6:20b:1a0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.13; Sat, 27 Jun 2020 06:10:35 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3153.012; Sat, 27 Jun 2020 06:10:35 +0000 From: Christer Holmberg To: "Dale R. Worley" , Maxim Sobolev CC: "sipcore@ietf.org" , "russp=40microsoft.com@dmarc.ietf.org" Thread-Topic: [sipcore] please review and comment on draft-penar-ietf-sipcore Thread-Index: AQHWRFAiFobhCNjPm0O8ZfoN1mHypajsCj0g Date: Sat, 27 Jun 2020 06:10:35 +0000 Message-ID: References: (sobomax@sippysoft.com) <87lfkm4dw9.fsf@hobgoblin.ariadne.com> In-Reply-To: <87lfkm4dw9.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6077d64-0362-4eb6-51d8-08d81a60ce45 x-ms-traffictypediagnostic: AM7PR07MB6529: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0447DB1C71 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bOWT4+9eIQUKoAMNDqCfNfcj96ETg905VcJq2o1XJlx3wRRIELrKjwQ6wdLh1xWuFeHnZQ9ShCZd8UHFMnRqAM5iOtzUNIZQ1px56wN5E5ykVemr5T2YCw9WX+n2Bkfm+AEwVAyZWvUQ6B2ezPqn3rJglwkeRrsyx3clq1hvq4yfvvlDIJVYk8PbA9qoxlwycqBIJj2/lj+4TtsOUp0slo+k5Wkz5vRNVqEAykshCizKUazdP8QBmrGzusNeaWEw4FBiTXuv+Ofv1GzqxBddgHp0ZcXElo49XEwgYzaZ1h72nWYaR+tYLpcP4MOOl9Ez x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(366004)(396003)(376002)(39860400002)(71200400001)(55016002)(66556008)(76116006)(54906003)(6506007)(4326008)(66946007)(110136005)(64756008)(26005)(186003)(4744005)(7696005)(478600001)(9686003)(316002)(44832011)(86362001)(66446008)(8676002)(5660300002)(33656002)(8936002)(2906002)(52536014)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: D44DHbn7KmIr9AtGlZwCI3Gx3P0KMSMpK0vus18Ul7s+uOAgmGrlYAEnMx4Ng2XfKDj/UCtNMUfIlGmjzG6ty0MI6tV/r+z5220SgatK/FeEsgMrgS9awuBcMhZVb870ayHZZYgd+YdUzUkH6vDmxa5eomr5tI9LzecMNESCDdWYMDsD1kocju9MjvkhbUuEfE49O0V1lnNNfJ9HHVCHbomZoAaWD9z6w6psNlYo62V8zFgfZY/LIQsXPjarp7s+qlSYIPTJCYnwxT6rZE23Apxq3xv3/xM4u3wc5O2lL2/Diw6QKWUcK/U0vXv3tbPF5YKiGOl2FQbAJ27FXKrfnwxc6rol3k4ddKYKJOywGGVhuSgkt0kSxLR1a5Shy5/zkon/WuM5k0mlps7KGU4MBNiVXyQqIlbH2ohadXwlkc6s0ajAnDVhnpm3lA8mPyZYVQwxjW48Y9pC5Zuk32LpesahfvJTyAa2uu7UIKFQNzLbMZOfK6YeioR5eryv4K+Y x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB7012.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6077d64-0362-4eb6-51d8-08d81a60ce45 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2020 06:10:35.1851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RH0iSkJR4QgWW+p6Ap1LauieDEyodJtz2rMzXw9u3EPMnd7HcTVIIBCSPmQSPvnG+TY930rCIhZXt0kNFNYvSl3p4yEzH1huND8DmYLmRSw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6529 Archived-At: Subject: Re: [sipcore] please review and comment on draft-penar-ietf-sipcore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 06:10:39 -0000 Hi, >> That actually a great idea Dale, I was thinking along the same lines=20 >> yesterday but dismissed the idea as too extravagant. Nobody prevents=20 >> multiparty body to carry on both "Rating" and media description! On=20 >> the implementation side of things, handling multiparty in 183 would be=20 >> way less expensive proposition, compared to adding new class of status c= odes. IMHO. > > In regard to multipart bodies, I would worry that some UAs would not look= within them to find the SDP. > > But it seems intrinsic to your use case that the rating will be generated= before a session description is -- the rating will be generated before the= INVITE is allowed to reach a UA. Correct. If the 183 is generated by the called party proxy, it may not have= to include SDP. Regards, Christer From nobody Sat Jun 27 02:59:30 2020 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 304583A060A for ; Sat, 27 Jun 2020 02:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo9MY8TVzIl6 for ; Sat, 27 Jun 2020 02:59:27 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 EE91B3A02C1 for ; Sat, 27 Jun 2020 02:59:26 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id bh7so5206983plb.11 for ; Sat, 27 Jun 2020 02:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fzb7BSEZauaN48Da9UI9CG3WeSEH+uTuGY5tSZp6Ta4=; b=QdYFSWqbXkNX/jEPY+hIQ34XMpOEXHewye3lpVIq0MhYzOMdPCvlGb/DLSBKxussqw GQ1hCPl4yAxG8IMmqHNemd3s+F5qThhIFIXk6kzA3GB7vy7rBsiP/l4pI6npGhyzQ0RA mrcT2HPQFtQA5j7gWIH5AWw64RxXuEa4E55QPIHUNHnubyqe0stGWpIMb5EaNtT3HUbv XXhcLZnlqYymyl70Bd7f4hRZSjNdD5w8gLi8Zi8lZFDGszOruvDCbvZL/vH+UTjeE7aB mSNfoNNDRdz2uAVKJj4gDc2j5dSOCMaoOdClodAc3gHBK1Km0nFFodb/r4pStq/AimBu mOeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fzb7BSEZauaN48Da9UI9CG3WeSEH+uTuGY5tSZp6Ta4=; b=V0KHb/HWoXttiPz2QiBQfmaN5c8MxwRjTMMp0A2Ueey0VxaV7r7VfsmG5R1hncVBxG g1ABtuMJCzkqvILRgYlXkSg7+e5tUhI+/VA7mu/TciMC31XnL7Kf/JaheHlvSdYY6cE1 og88a7vo0K/cgUMQo3dUAZL4kz8LpvlnQ+TXO7teYBBzD8Kx3zHNV7tqBB+9QzUJRCr/ KemYPnb2OHwV78vMZDNCWW8f0eAbw9JG26QOKRx/1Pfqr0UmTFI0sDQNTVwG02tEK0Dh J6YWp96VcrJTMnL1AOcVKOfRDGRtECQPXHRgerS2kHznkIpgdLAhovQ6wDMKPbE18wd/ pykw== X-Gm-Message-State: AOAM532DI5lsbI1M7tdlgzxhzrLUEV6y9lVKRnG/Lz09wSBBcPBz1xL8 /XGvCQ/K57nQ+oqeJ3L1pwc= X-Google-Smtp-Source: ABdhPJzPB5Dni2fYKUnnWISsMeVIy9a5dnjhAv+SV4PC0fWTBNaPHVpwQi/PnXOLnumDgmIsi2f22g== X-Received: by 2002:a17:90a:a115:: with SMTP id s21mr2344659pjp.232.1593251966442; Sat, 27 Jun 2020 02:59:26 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id m12sm1463862pjf.17.2020.06.27.02.59.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 02:59:25 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount References: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> From: OKUMURA Shinji Message-ID: <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> Date: Sat, 27 Jun 2020 18:59:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200627-0, 2020/06/27), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 09:59:28 -0000 Roman, On 2020/06/24 23:17, Roman Shpount wrote: > On Wed, Jun 24, 2020 at 5:23 AM OKUMURA Shinji > wrote: > >> 1. Why SHOULD the Session-Expires header field be present? >> A UA1 sent an initial INVITE without a Session-Expires header, then UA1 >> became a refresher. >> UA1 didn't a session-timer, and so it did not add a Session-Expires header >> to the INVITE. >> As a perspective of UA, adding a Session-Expires header means that it own >> needs a session-timer. >> But UA1 doesn't need it even now. In this situation, why SHOULD the >> Session-Expires header field be present? >> > > This is an optimization. Setting Session-Expires to an existing session > timer value avoids session timer re-negotiation and potential 422 responses. Even if there is no Session-Expires header, negotiation is always done. And if the Min-SE header shows the maximum value in the dialog, then no 422 response will occur. In other words, the Session-Expires header has nothing to do with optimization. > 2. What SHOULD the value be equal to? >> In general, the maximum of the Min-SE header field is not equal to the >> current session interval. >> It is ambiguous. In the first place, a UAC doesn't always know the exact >> maximum. > > It is the maximum of Min-SE set by UAC and the current Session-Expires > value for the dialog. UAC knows both. My question is whether the value set in the Session-Expires header is the maximum of the Min-SE header field or the current session interval. Probably this is an editorial error. > 3.Why dose inclusion of the Session-Expires header field with this value >> avoid certain denial-of-service >> attacks? >> >> Section 11.1 says: >> ===================================================================== >> Next, consider the case of a rogue UAS that wishes to force a UAC to >> generate refreshes at a rapid rate. In that case, the UAC has to >> support session timer. The initial INVITE arrives at the rogue UAS, >> which returns a 2xx with a very small session interval. The UAC uses >> this timer and quickly sends a refresh. Section 7.4 requires that >> the UAC copy the current session interval into the Session-Expires >> header field in the request. This enables the proxies to see the >> current value. The proxies will reject this request and provide a >> Min-SE with a higher minimum, which the UAC will then use. >> ===================================================================== >> >> As I pointed out earlier, if the rogue UAS returns a 2xx with a very small >> session interval again, the attack will continue. IMO the important point >> is that UAs need to know the maximum value of the Min-SE header field in >> the dialog. According to the current regulations, only the UAS can know the >> maximum value. I think that 2xx response should include Min-SE header. And >> proxies should check it. >> > > In general I agree but it is not an entirely backwards compatible change. To address this security consideration, UAC needs to know the maximum value of the Min-SE header in the dialog. I think there are following solutions. 1. UAS copies a Min-SE header into 2xx response for an initial INVITE. I think this procedure is adequately backward compatible. 2. When a dialog is established, UAS sends a session refresh request. This is an entirely backwards compatible. 3. When a dialog is established, UAC sends a session refresh request with low Min-SE or no Min-SE. UAC can know the maximum value of the Min-SE by 422 response. This is an entirely backwards compatible. Regards, Shinji From nobody Sat Jun 27 03:07:45 2020 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 C8E9F3A0788 for ; Sat, 27 Jun 2020 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8aR9LZ7wTaY for ; Sat, 27 Jun 2020 03:07:41 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 B4DC93A0778 for ; Sat, 27 Jun 2020 03:07:41 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id j12so5745769pfn.10 for ; Sat, 27 Jun 2020 03:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5u2Xgp9CwXtKfoABhfe4JyD8Dzyrwfg4JPcLXkXVn+Q=; b=bQdtaQLq+0u2guzGZLjKLG2roJQkBD97kUY18ZvYtEbeZP+WboAYLy83gT5Rx9lAxX 7oiX+84VHKvfQXNAYNdH7mua6Q9CXPpKEpJtPQFU6yYM3S17+jVxKGsQC+OuiaPJIJbI CD36QCnAhG8+ul687ZAiL8t/pmjNFzXV1MRsRnpnDuu0SX0VNfZ/6bWa8RNvPOaZS/Qa fax3T9mBLh4YILCzq76JGjkmgHysISMFC0bJR0Gf+yoE8HMLlBcWeCep/Q64AYjbninj vIoUkPPvxtVFHo/x5b7c8rt0UKjm8ov+eay+AlJVi4mNCyne1ZIhRqFkdtg3uQfwTwoZ YV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5u2Xgp9CwXtKfoABhfe4JyD8Dzyrwfg4JPcLXkXVn+Q=; b=V8u/nzE34Ivi7KvOx/oW/N8T/tj+c8Hyk3e8EolXUTLbRfeegOxwKMdoJFq8/ukQRF KpOEyStqEdn2VTHaq5yMW4p3nYr0lOVxXM3EBv6l384hgzsgeda1HqDy7aBHNzP8IUul EPXwhYYDjdyJ7dL0L/uPwUm2ym9FcgExzr8QbuSF//WaV5jQrTWlHYIjTWAG9PTO5q8i Ng4T244+m73bwPdImGc/BtUyArxXiLEPDdJVAiqyOFpdoe0THKY+LnYad9SytQ/QuvvI JbVZ8XHo+cMK0na7+X7mwX6zmhi2CZI0XiGFXrgSwJv0JvkcAQFVc32ullM4Twb1XLeG 9Gag== X-Gm-Message-State: AOAM531kCakJ5hlyb6YSCMVda6+3G0/+def57tKafliaD0GeansiiFLP 9IvXefW1yJputPBhxTXiB9A= X-Google-Smtp-Source: ABdhPJxeuZDar/pUY7lDYorkVuuspNi5ekr/f3LnFhm3TV5VGBil1vcdhpV4nNbqZGKdLzenjGJEsg== X-Received: by 2002:a63:c44b:: with SMTP id m11mr2548814pgg.404.1593252461136; Sat, 27 Jun 2020 03:07:41 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id p12sm28541295pfq.69.2020.06.27.03.07.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 03:07:40 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Cc: Roman Shpount References: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> Message-ID: <9f812539-3e26-c601-a77c-f8a538ede556@gmail.com> Date: Sat, 27 Jun 2020 19:07:31 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200627-0, 2020/06/27), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 10:07:44 -0000 > Even if there is no Session-Expires header, negotiation is always done. ^^ Even if there is a Session-Expires header, negotiation is always done. ^ On 2020/06/27 18:59, OKUMURA Shinji wrote: > Roman, > > On 2020/06/24 23:17, Roman Shpount wrote: >> On Wed, Jun 24, 2020 at 5:23 AM OKUMURA Shinji >> wrote: >> >>> 1. Why SHOULD the Session-Expires header field be present? >>> A UA1 sent an initial INVITE without a Session-Expires header, then UA1 >>> became a refresher. >>> UA1 didn't a session-timer, and so it did not add a Session-Expires header >>> to the INVITE. >>> As a perspective of UA, adding a Session-Expires header means that it own >>> needs a session-timer. >>> But UA1 doesn't need it even now. In this situation, why SHOULD the >>> Session-Expires header field be present? >>> >> >> This is an optimization. Setting Session-Expires to an existing session >> timer value avoids session timer re-negotiation and potential 422 responses. > > Even if there is no Session-Expires header, negotiation is always done. > And if the Min-SE header shows the maximum value in the dialog, then no 422 response will occur. In other words, the Session-Expires header has nothing to do with optimization. > >> 2. What SHOULD the value be equal to? >>> In general, the maximum of the Min-SE header field is not equal to the >>> current session interval. >>> It is ambiguous. In the first place, a UAC doesn't always know the exact >>> maximum. >> >> It is the maximum of Min-SE set by UAC and the current Session-Expires >> value for the dialog. UAC knows both. > > My question is whether the value set in the Session-Expires header is the maximum of the Min-SE header field or the current session interval. Probably this is an editorial error. > >> 3.Why dose inclusion of the Session-Expires header field with this value >>> avoid certain denial-of-service >>> attacks? >>> >>> Section 11.1 says: >>> ===================================================================== >>> Next, consider the case of a rogue UAS that wishes to force a UAC to >>> generate refreshes at a rapid rate.  In that case, the UAC has to >>> support session timer.  The initial INVITE arrives at the rogue UAS, >>> which returns a 2xx with a very small session interval.  The UAC uses >>> this timer and quickly sends a refresh.  Section 7.4 requires that >>> the UAC copy the current session interval into the Session-Expires >>> header field in the request.  This enables the proxies to see the >>> current value.  The proxies will reject this request and provide a >>> Min-SE with a higher minimum, which the UAC will then use. >>> ===================================================================== >>> >>> As I pointed out earlier, if the rogue UAS returns a 2xx with a very small >>> session interval again, the attack will continue. IMO the important point >>> is that UAs need to know the maximum value of the Min-SE header field in >>> the dialog. According to the current regulations, only the UAS can know the >>> maximum value. I think that 2xx response should include Min-SE header. And >>> proxies should check it. >>> >> >> In general I agree but it is not an entirely backwards compatible change. > > To address this security consideration, UAC needs to know the maximum value of the Min-SE header in the dialog. > I think there are following solutions. > > 1. UAS copies a Min-SE header into 2xx response for an initial INVITE. I think this procedure is adequately backward compatible. > > 2. When a dialog is established, UAS sends a session refresh request. This is an entirely backwards compatible. > > 3. When a dialog is established, UAC sends a session refresh request with low Min-SE or no Min-SE. UAC can know the maximum value of the Min-SE by 422 response. This is an entirely backwards compatible. > > Regards, > Shinji From nobody Sat Jun 27 04:02:31 2020 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 808E23A00E0 for ; Sat, 27 Jun 2020 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQd9GFIQ7kdW for ; Sat, 27 Jun 2020 04:02:28 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 1617C3A00DF for ; Sat, 27 Jun 2020 04:02:28 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id b92so6004734pjc.4 for ; Sat, 27 Jun 2020 04:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jC0ZDiold3UK2ZbknD+rT9DlUaT9+PmzrwXLkw/hAu0=; b=SdZF2a45hOxFdt5837j5FnLxCBgn/WS4idnvcYGT0TUaUWIVmDLLRswctxYWuYgTpU unzu6RCGllbi+nbKMIXbyDa8tmbFcIEOtCGJO4dQ27pn2RHeckHPrQOnc+TRH0mTUPP9 UWkBzIYuB6iapnpeaLZzlCI8QZa31byd0covXZQDJdYXmdR/XgKuwqzSIw6bFEr0t4j8 gJzDAoULl60DwrPG13x+mFrt5kaP6b2wIi2Ux96ZUm0+eD5v4yvk0MC5b6Qcj3IvHDEM MhtE26p3XsK77olS3KAjSPMHq5JzACD6+jCksBVyWtjUCZgvDlQimiyuy9Y3apYEtbGg 1Ucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jC0ZDiold3UK2ZbknD+rT9DlUaT9+PmzrwXLkw/hAu0=; b=LhJRdyEIvnnpBBdpAYURYmLoGjwSVfsfJ7sBF7/iFK8Az2QBlcG+vdRBhOepdLDTT3 7FWUvakFWn9fcFllNLEJ5kXY3tiDudHoUjXkRqJklGKWO/qbFtfg4FHtO8RsmIVch6WD xLVthL8eg5HKYi5B3mwDRPF1Iu5q/zs9V4i8pHBfVrQ4g0MVssEbFudzAu4TZc8pn8la sphNxqsXfm227b7rGNYJt++FeQ0OpSCmKgC3B8S6URNmUoFgxfunUD5RMo88BU88yd7r vaaqFPLI+oIE+J1mzY/Fp8Byz7Hco2mvXN/W3WtyrrapjkqDB4X6G9SHyrzpzSKUFwG8 QLVQ== X-Gm-Message-State: AOAM533IUjp7ne/k4vSVn+LbOoJAaOfv0DV7ePL7KyX3EF4r2f7ndC6E HJmOQNIpcmDeyDT9THnJ8y5yfu3h X-Google-Smtp-Source: ABdhPJx23oYEjWpmJiXRtrwRs6lT/jjE6YUYxRfHYpWNte/RRGdWont/a5rJsqQBUcO30notlAHBuQ== X-Received: by 2002:a17:90a:fb90:: with SMTP id cp16mr3484001pjb.47.1593255747253; Sat, 27 Jun 2020 04:02:27 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id b19sm27630911pft.74.2020.06.27.04.02.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 04:02:26 -0700 (PDT) To: Paul Kyzivat , Roman Shpount Cc: SIPCORE References: <0c2ccc26-d895-9a3c-5fb1-c838c4df18df@gmail.com> <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> From: OKUMURA Shinji Message-ID: Date: Sat, 27 Jun 2020 20:02:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200627-0, 2020/06/27), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 11:02:30 -0000 Hi Paul, All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? Regards, Shinji On 2020/06/26 4:24, Paul Kyzivat wrote: > Roman, > > On 6/25/20 2:20 PM, Roman Shpount wrote: >> Hi Paul, >> >> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >> >> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >> >> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. > > My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. > > I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. > > It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. > >     Thanks, >     Paul > >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >> >>     ISTM that the key issue Shinji is raising is that it could be >>     problematic to raise an error to an UPDATE that is doing a target >>     refresh. This is true regardless of what else the UPDATE is doing - an >>     offer, session timer refresh, or maybe nothing else. >> >>     The bottom line here is that if you have an urgent need to do a target >>     refresh, you should do it with a request that has little to no >>     chance of >>     being rejected. >> >>     This is of course under the control of the UAC. If the UAC chooses >>     to do >>     a target refresh with an UPDATE, and in conjunction with a session time >>     refresh (and/or offer) then it should be prepared for the consequences >>     if the UPDATE is rejected (with 491 or anything else.) >> >>     I guess we could discuss how much (if any) of this logic ought to be >>     included in the document. >> >>     I don't think this alters the validity of using 491 for a session timer >>     glare situation. >> >>              Thanks, >>              Paul >> >>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>     >>      > >> wrote: >>      > >>      >      >> 1. Handling of UPDATE with no SDP glare >>      >      >> I'm not going to deny the solution with the 491 response, >>     but I >>      >     think it has a big impact. >>      >      > >>      >      > The situation with session timers is different from target >>      >     refresh. Target refresh is updated for each UA independently. >>      >     Session timer is negotiated for the entire session, so more >>      >     collision scenarios are possible. One of such scenarios is >>     both UA >>      >     sending UPDATE at the same time. If these UPDATE requests do not >>      >     carry SDP, currently they should be accepted. Resulting session >>      >     timer state is ambiguous. The only reliable way to prevent >>     ambiguous >>      >     session timer state in this case is to refuse the UPDATE message, >>      >     similar to the session description collision. This is why 491 was >>      >     suggested. >>      > >>      >     First of all, is a 491 rejected solution planned for bis? >>      > >>      > >>      > It was discussed but nothing is final. >>      > >>      >     If so, the UPDATE for target-refresh and the one for >>     session-refresh >>      >     are combined, as such they affect each other. And I think the >>     result >>      >     will be rarely ambiguous, if there is no change in the >>     session timer >>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>      >     reject the UPDATE request? If the UPDATE with new >>     remote-target-uri >>      >     is rejected, the UA will be unreachable. >>      > >>      > >>      >   This should be no different than the UPDATE with SDP collision. >>     I am >>      > not sure what problem you are talking about. >>      > >>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>      >      > This is exactly the reason why handling of UPDATE transaction >>      >     collisions needs to be resolved. If session timer ends up in an >>      >     ambiguous state, it is likely ambiguous for both UA and both >>     UA will >>      >     initiate an UPDATE refresh request to confirm, which will >>     result in >>      >     a collision. >>      > >>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>     to avoid >>      >     collisions on retransmission. And we also need to decide how UAs >>      >     detect collisions. >>      > >>      > >>      > I am not sure what you are talking about. >>      > _____________ >>      > Roman Shpount >> > From nobody Sat Jun 27 08:45:46 2020 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 584903A079D for ; Sat, 27 Jun 2020 08:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 mtTzaOFWXNc5 for ; Sat, 27 Jun 2020 08:45:43 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2044.outbound.protection.outlook.com [40.107.220.44]) (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 236153A00B0 for ; Sat, 27 Jun 2020 08:45:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZdnpdFCLfuFsMIX2msxQdgBf6fGnswKCJSwlmSR+VwXgCr0A2NmR/XsNaE67nkih/QJ7W208m7/tOYk2rmCrWnJ60Pu4UhNQE541NnLGOgAmbWjamFYHNx3vspHLrCtYGCcj6hOMw4gmFTJHMtgiCz3EP0Jpwp0zxpbxQcYeK6kpEwnNC3S+NFR3GzjSO+ziatSJdPdyaxzgC1d9dYCc/FOihHpMxvhemV5pbB2rw8MuQ8nYVYpXd9tf6D2OoluiVkwK2QJZMBqG4+raPbKOdGd10AaZQnFqJBBCva3iGzfjplDIBJUDIohUd3IxBbbuUne+squMHwmd+zhYiGDWpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ByHbmbLXjhw6C2qFt4tUpbmNInPdEskIZhYm1mSmjs=; b=GV8xzmpOEgbjagr7sf8nbMbOs7OyWpCRZB/j+9qV2JeFhu+vY2YNbyuWOsjeEzH6vW0xMBqxKk3aotoKYzU0VQepKy9jqL8/8ck7vxKEOMs/R462b4mDg8+lkMQziXYD6G2ME5gcRzi97IsUlTd1mZ5xylnD33q5cIbsY81Se8wX46v6QtGq4fb30JccU+BXPaSfgp5CrTZSzdqyl8E/T0myh66sgPaE9dTuNLw/Ke6EFfN6v/pueTjQLSiPuI4qj99CK5laKHk+snDm5p0kQLbDiTt9OwfvTT7omFsuapUB4FaGyMYxK/HamUopGOuqinsaTQ5spNFDESl2DUWaRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ByHbmbLXjhw6C2qFt4tUpbmNInPdEskIZhYm1mSmjs=; b=PRpzLxuUdJxOlnMsK6Zvol0NFeuu9zLHH9bIJBea2mSsHjeK7M01tmRbKBhdGvrYBgxVOEb6d6DhUkYanbqKIjHFXUTAuRm7CdiC8J52tVaGQLnecf7RdzWO0yE7qk0kMMsvUEulCXcvxc9Jqm1gOy1Qn2I/cQvkl2zdbIujoO0= Received: from CY4PR14CA0038.namprd14.prod.outlook.com (2603:10b6:903:101::24) by BN8PR12MB3441.namprd12.prod.outlook.com (2603:10b6:408:49::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Sat, 27 Jun 2020 15:45:41 +0000 Received: from CY1NAM02FT037.eop-nam02.prod.protection.outlook.com (2603:10b6:903:101:cafe::62) by CY4PR14CA0038.outlook.office365.com (2603:10b6:903:101::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23 via Frontend Transport; Sat, 27 Jun 2020 15:45:41 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT037.mail.protection.outlook.com (10.152.75.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Sat, 27 Jun 2020 15:45:40 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05RFjcp8000867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 27 Jun 2020 11:45:39 -0400 To: OKUMURA Shinji , Roman Shpount Cc: SIPCORE References: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> From: Paul Kyzivat Message-ID: <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> Date: Sat, 27 Jun 2020 11:45:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(346002)(396003)(376002)(39860400002)(136003)(46966005)(8936002)(15650500001)(82740400003)(8676002)(316002)(786003)(478600001)(31696002)(36906005)(5660300002)(31686004)(47076004)(7596003)(70206006)(110136005)(4326008)(86362001)(186003)(356005)(82310400002)(2616005)(956004)(26005)(2906002)(53546011)(83380400001)(70586007)(336012)(75432002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 613ccb00-5f20-4434-8dfc-08d81ab1255c X-MS-TrafficTypeDiagnostic: BN8PR12MB3441: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0447DB1C71 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IcomLuz+VPt4+rYZypkSpoix81nuQSW5wgPrIxg8pVJbfGhoAanwvduW5y2Ck95DneChjcvCyMa4mL3I1HXkg3++bUpQdSoGXaPqhvJyCG6BsH+8m+37ZO1aWSL+OhNLAbQd2JkHK/j1+CgS24SHfckySrc8L4SZ4p8wuF29DnUzam6AGfaFhD87Lh+bEAZVkHsp+4fXDC4JvLfiy5p4QyxeLnps6vwJ++W60p6WxGbaPQzxLESPxfxQxqCPPJidQi1vwrDWDKvIEaDWenE9PgFeuNW/QYlLkMb187Pdej0ypbSvZgW3PGXH2IEtb1ys2E8bbE8k9azM7GV7OfgOr3JtQYtJbdv3UkPfgAVR/Q/cXAhrss+Cps7hZ8S8/PsE9eDs2Nex6D8/+OAcSruwGVWupxXG6ecELF3vDBI8/mVszCtdBQZSju8/6Tx48uAo X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2020 15:45:40.8522 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 613ccb00-5f20-4434-8dfc-08d81ab1255c X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT037.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3441 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:45:45 -0000 On 6/27/20 7:02 AM, OKUMURA Shinji wrote: > Hi Paul, > > All I want to confirm is one point. If a UA receives a session refresh > request during another session refresh transaction, the UA MUST reject > it with a 491 response, or MAY reject it with a 491 response. If we want to follow the precedent of O/A glare, then I think it is MUST reject. > A UA > accepts both requests, compares two results, (if necessary) sends > additional request for confirmation. I don't have to worry that my > desired implementation is a protocol violation, right? I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. Thanks, Paul > Regards, > Shinji > > On 2020/06/26 4:24, Paul Kyzivat wrote: >> Roman, >> >> On 6/25/20 2:20 PM, Roman Shpount wrote: >>> Hi Paul, >>> >>> First of all, the issue with target refresh that Shinjit was raising >>> is not new. It affects session description updates as much as it does >>> session timers. >>> >>> Second, I am not sure there is an actual problem. Target refresh is >>> done via a SIP transaction, so it does not happen instantaneously. >>> SIP transactions can be delayed due to proxy processing or network >>> delays, as well as due to a packet loss. The delay introduced by 491 >>> error response is generally comparable to transaction delay, so it >>> normally does not introduce any new problems. All that should happen >>> due to a 491 response, is that the transaction should be retried with >>> some delay and target refresh should happen slightly later. >>> >>> Considering that this is an existing design consideration which is >>> not specific to SIP session timer, I do not think it warrants a >>> discussion in the session timer document. >> >> My text was mostly just me explaining my reasoning for purposes of the >> discussion. I'm inclined to agree that it doesn't need to be discussed >> in the ST draft. It is not a new concern as far as whether to use 491 >> to resolve ST glare. >> >> I have a feeling we are all in agreement that the notion of glare >> during session timer refresh is a real thing, and that extending the >> use of 491 to apply to that situation is appropriate. >> >> It isn't strictly backward compatible. But if a UAS uses it, I bet >> there is a pretty good chance that a UAC receiving the 491 in that >> context will do the right thing, or at least something reasonable, >> even if it hasn't been updated for this change. Worst case is for the >> call to fail. >> >>      Thanks, >>      Paul >> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat >> > wrote: >>> >>>     ISTM that the key issue Shinji is raising is that it could be >>>     problematic to raise an error to an UPDATE that is doing a target >>>     refresh. This is true regardless of what else the UPDATE is doing >>> - an >>>     offer, session timer refresh, or maybe nothing else. >>> >>>     The bottom line here is that if you have an urgent need to do a >>> target >>>     refresh, you should do it with a request that has little to no >>>     chance of >>>     being rejected. >>> >>>     This is of course under the control of the UAC. If the UAC chooses >>>     to do >>>     a target refresh with an UPDATE, and in conjunction with a >>> session time >>>     refresh (and/or offer) then it should be prepared for the >>> consequences >>>     if the UPDATE is rejected (with 491 or anything else.) >>> >>>     I guess we could discuss how much (if any) of this logic ought to be >>>     included in the document. >>> >>>     I don't think this alters the validity of using 491 for a session >>> timer >>>     glare situation. >>> >>>              Thanks, >>>              Paul >>> >>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>     >>>      > >> >>> wrote: >>>      > >>>      >      >> 1. Handling of UPDATE with no SDP glare >>>      >      >> I'm not going to deny the solution with the 491 response, >>>     but I >>>      >     think it has a big impact. >>>      >      > >>>      >      > The situation with session timers is different from target >>>      >     refresh. Target refresh is updated for each UA independently. >>>      >     Session timer is negotiated for the entire session, so more >>>      >     collision scenarios are possible. One of such scenarios is >>>     both UA >>>      >     sending UPDATE at the same time. If these UPDATE requests >>> do not >>>      >     carry SDP, currently they should be accepted. Resulting >>> session >>>      >     timer state is ambiguous. The only reliable way to prevent >>>     ambiguous >>>      >     session timer state in this case is to refuse the UPDATE >>> message, >>>      >     similar to the session description collision. This is why >>> 491 was >>>      >     suggested. >>>      > >>>      >     First of all, is a 491 rejected solution planned for bis? >>>      > >>>      > >>>      > It was discussed but nothing is final. >>>      > >>>      >     If so, the UPDATE for target-refresh and the one for >>>     session-refresh >>>      >     are combined, as such they affect each other. And I think the >>>     result >>>      >     will be rarely ambiguous, if there is no change in the >>>     session timer >>>      >     policy of each entity(UAC, proxies and UAS). Even so, >>> should UAs >>>      >     reject the UPDATE request? If the UPDATE with new >>>     remote-target-uri >>>      >     is rejected, the UA will be unreachable. >>>      > >>>      > >>>      >   This should be no different than the UPDATE with SDP collision. >>>     I am >>>      > not sure what problem you are talking about. >>>      > >>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>      >      >> RFC6141 says, if in doubt, send a refresh request to >>> confirm. >>>      >      > This is exactly the reason why handling of UPDATE >>> transaction >>>      >     collisions needs to be resolved. If session timer ends up >>> in an >>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>     UA will >>>      >     initiate an UPDATE refresh request to confirm, which will >>>     result in >>>      >     a collision. >>>      > >>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>     to avoid >>>      >     collisions on retransmission. And we also need to decide >>> how UAs >>>      >     detect collisions. >>>      > >>>      > >>>      > I am not sure what you are talking about. >>>      > _____________ >>>      > Roman Shpount >>> >> From nobody Sat Jun 27 11:38:40 2020 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 464833A08A2 for ; Sat, 27 Jun 2020 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 X3oRK6NOr9hG for ; Sat, 27 Jun 2020 11:38:37 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2068.outbound.protection.outlook.com [40.107.223.68]) (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 D64943A0891 for ; Sat, 27 Jun 2020 11:38:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c2NycU5U14aqPHfvOLksWR8MMJMZtuvBTwluovaLPc1tltxt4eHJbXgyS9oNoytDt+MBfiTFxNa2jWmECeaaSlDmsghBhd8IqROfWqhd/sU/4GbniPcSQyTtAM/z0Vka3dn8i5tmykpDdtXVoWdSEOAGRWeIs7uhtlLRSQfu/9jAugP0NIGx6rDSq1yUVenl/Z1W78LYrIc71mTsAHjFz+sNWGJiQUrljENyBmjQcqPHmLaOpPkrQA5BvTNf+pDi407E7eNOI3i0kV5x5XatrT1whP3rk+3ADl6WcpDt8kX86iN8seYOFSnU9GWD9R7wieU5i9mAR5AlIt96Uen2Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CXZ9vBPHamIDdjyuXXkGNhwOD3xjmIfQjxpGNK7bHLg=; b=Zl+FksfM/qLWrRYws08MeRF+OTCQff53/QqV6veviGZMFncET++LsdPTT6wh9X2RVWa+1/sjuBBFK18kWgYIUrw3DsuWdPiD628smtNmn1RsAl7erZKyNFN3htHmhozVoKV7SG9ALtLuiHOiO68GWbc0CWgrVHsvoMTKIr8reqK8SBl8PW9UWwBJ8Z57Z7lZmwdrerm4oau9aP25sCL16lSMNutjVFwJTahf2scNsHAQcjddCLK7Y+GwG8x8sxFVtjK3Gc6jLtSufU0/0sKQEy3z2K8B6imzudCHutm1YEzLvSybrp4hatcHvueXSu29HAckm+OINi6M7b52LHjDGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CXZ9vBPHamIDdjyuXXkGNhwOD3xjmIfQjxpGNK7bHLg=; b=NfxNfSxxl1M4IqU48r9OysdlKz5SRk4XUDVWmzT2LmGZNnnCYiGZlv89VIaNz63fXyZzBi9h38d/acEtYh1MrKrR7RASBvsxn3nWs2c3CYtT/dfUczEFsnpiXtLyN4YR2gqPghLVaDV28QFndZqzXVnJQtGApQ/xhEBgQIP2W4w= Received: from MN2PR10CA0026.namprd10.prod.outlook.com (2603:10b6:208:120::39) by MN2PR12MB2960.namprd12.prod.outlook.com (2603:10b6:208:101::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Sat, 27 Jun 2020 18:38:35 +0000 Received: from BL2NAM02FT032.eop-nam02.prod.protection.outlook.com (2603:10b6:208:120:cafe::84) by MN2PR10CA0026.outlook.office365.com (2603:10b6:208:120::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Sat, 27 Jun 2020 18:38:35 +0000 X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of alum.mit.edu: DNS Timeout) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT032.mail.protection.outlook.com (10.152.77.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Sat, 27 Jun 2020 18:38:33 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05RIcWYf012760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 27 Jun 2020 14:38:33 -0400 To: sipcore@ietf.org References: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> From: Paul Kyzivat Message-ID: <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> Date: Sat, 27 Jun 2020 14:38:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(346002)(396003)(376002)(39860400002)(46966005)(86362001)(356005)(7596003)(82310400002)(956004)(15650500001)(83380400001)(53546011)(2616005)(26005)(63350400001)(5660300002)(186003)(6916009)(336012)(316002)(36906005)(786003)(2906002)(70586007)(70206006)(31686004)(478600001)(75432002)(82740400003)(8936002)(966005)(47076004)(31696002)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 36553625-1c8e-4528-58d6-08d81ac94bf5 X-MS-TrafficTypeDiagnostic: MN2PR12MB2960: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0447DB1C71 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ey2Z38yx7kew+J0Z2R/TWhGkeTrhY8fju9HiZO4bDI+4HuW+aJVAweN7RCTwCNKH30D1559dsddROgh8gaYDw0mJKiQO/1eOT10Y826am1uRtExIWD+k48meZzI7KMz5pVSwcx81D9CTF2DcBnYEQuVb0MHYKf4tDjatYofJ/qEOmr45TSvzINj6qPMyM8EqmdKC3ATxn/VIVwjVOBV7gIU3WQB4Lmrs+1QBClQ7tTw7Prdh57s3IuB3BkzF55nPv581T0K3AqHi6A7lAXYEYQtyVV6NcJoD8IiIDj6lUl3xx7qXRss7mHl8N6aPBhpgUsqjziP2YNcvtCa3lkufFoEGvoJwgCudItLBEov+fjRumB5p/zy26dDH0qNamG/TfhhDpOBq/eA2gY/wSGyv1Ns0GiOsbpO1KAbF1FDkSKO/Ls4IeOqYZCsBNVIgHrw9Lr3qbjKnzb/EIM0ys3N+liF3s6jRk1eHqprlCXlHecBEsmxg27wmt0THWaJ9w1O4 X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2020 18:38:33.7444 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 36553625-1c8e-4528-58d6-08d81ac94bf5 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT032.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB2960 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 18:38:39 -0000 Some further thoughts on this... On 6/27/20 11:45 AM, Paul Kyzivat wrote: > On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >> Hi Paul, >> >> All I want to confirm is one point. If a UA receives a session refresh >> request during another session refresh transaction, the UA MUST reject >> it with a 491 response, or MAY reject it with a 491 response. > > If we want to follow the precedent of O/A glare, then I think it is MUST > reject. > >> A UA accepts both requests, compares two results, (if necessary) sends >> additional request for confirmation. I don't have to worry that my >> desired implementation is a protocol violation, right? > > I'm sure there are situations where the two ends can arrive at a common > understanding without raising the 491. But I think the complexity of > spelling out the cases so things are deterministic is not worth the > added effort and resulting complexity in the spec. I subsequently realized that if we specify the use of 491 for ST then we must consider what happens in cases of interop with an older implementation that doesn't do that. If we have one UA supporting the extension and one that doesn't we first will have to decide whether to use an option tag so the two can know who does and doesn't support them. If so, then the 491 would not be used by either end in ST glare cases, and everything would work as currently. If no option tag is used, then the UA that supports it may send a 491 to indicate glare, but the other end won't, and also won't know precisely what to do when receiving one. We will then have to figure out what the end that does support the extension can do to fix things as best it can. In that case, it may be ok to allow the use of 491 to be optional, with the alternative being to proceed as if the other end doesn't support the extension. I think this probably suggests that an option tag for support of the updated ST draft would be helpful. >     Thanks, >     Paul > >> Regards, >> Shinji >> >> On 2020/06/26 4:24, Paul Kyzivat wrote: >>> Roman, >>> >>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>> Hi Paul, >>>> >>>> First of all, the issue with target refresh that Shinjit was raising >>>> is not new. It affects session description updates as much as it >>>> does session timers. >>>> >>>> Second, I am not sure there is an actual problem. Target refresh is >>>> done via a SIP transaction, so it does not happen instantaneously. >>>> SIP transactions can be delayed due to proxy processing or network >>>> delays, as well as due to a packet loss. The delay introduced by 491 >>>> error response is generally comparable to transaction delay, so it >>>> normally does not introduce any new problems. All that should happen >>>> due to a 491 response, is that the transaction should be retried >>>> with some delay and target refresh should happen slightly later. >>>> >>>> Considering that this is an existing design consideration which is >>>> not specific to SIP session timer, I do not think it warrants a >>>> discussion in the session timer document. >>> >>> My text was mostly just me explaining my reasoning for purposes of >>> the discussion. I'm inclined to agree that it doesn't need to be >>> discussed in the ST draft. It is not a new concern as far as whether >>> to use 491 to resolve ST glare. >>> >>> I have a feeling we are all in agreement that the notion of glare >>> during session timer refresh is a real thing, and that extending the >>> use of 491 to apply to that situation is appropriate. >>> >>> It isn't strictly backward compatible. But if a UAS uses it, I bet >>> there is a pretty good chance that a UAC receiving the 491 in that >>> context will do the right thing, or at least something reasonable, >>> even if it hasn't been updated for this change. Worst case is for the >>> call to fail. >>> >>>      Thanks, >>>      Paul >>> >>>> Best Regards, >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat >>> > wrote: >>>> >>>>     ISTM that the key issue Shinji is raising is that it could be >>>>     problematic to raise an error to an UPDATE that is doing a target >>>>     refresh. This is true regardless of what else the UPDATE is >>>> doing - an >>>>     offer, session timer refresh, or maybe nothing else. >>>> >>>>     The bottom line here is that if you have an urgent need to do a >>>> target >>>>     refresh, you should do it with a request that has little to no >>>>     chance of >>>>     being rejected. >>>> >>>>     This is of course under the control of the UAC. If the UAC chooses >>>>     to do >>>>     a target refresh with an UPDATE, and in conjunction with a >>>> session time >>>>     refresh (and/or offer) then it should be prepared for the >>>> consequences >>>>     if the UPDATE is rejected (with 491 or anything else.) >>>> >>>>     I guess we could discuss how much (if any) of this logic ought >>>> to be >>>>     included in the document. >>>> >>>>     I don't think this alters the validity of using 491 for a >>>> session timer >>>>     glare situation. >>>> >>>>              Thanks, >>>>              Paul >>>> >>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>     >>>>      > >>> >> wrote: >>>>      > >>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>      >      >> I'm not going to deny the solution with the 491 >>>> response, >>>>     but I >>>>      >     think it has a big impact. >>>>      >      > >>>>      >      > The situation with session timers is different from >>>> target >>>>      >     refresh. Target refresh is updated for each UA >>>> independently. >>>>      >     Session timer is negotiated for the entire session, so more >>>>      >     collision scenarios are possible. One of such scenarios is >>>>     both UA >>>>      >     sending UPDATE at the same time. If these UPDATE requests >>>> do not >>>>      >     carry SDP, currently they should be accepted. Resulting >>>> session >>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>     ambiguous >>>>      >     session timer state in this case is to refuse the UPDATE >>>> message, >>>>      >     similar to the session description collision. This is why >>>> 491 was >>>>      >     suggested. >>>>      > >>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>      > >>>>      > >>>>      > It was discussed but nothing is final. >>>>      > >>>>      >     If so, the UPDATE for target-refresh and the one for >>>>     session-refresh >>>>      >     are combined, as such they affect each other. And I think >>>> the >>>>     result >>>>      >     will be rarely ambiguous, if there is no change in the >>>>     session timer >>>>      >     policy of each entity(UAC, proxies and UAS). Even so, >>>> should UAs >>>>      >     reject the UPDATE request? If the UPDATE with new >>>>     remote-target-uri >>>>      >     is rejected, the UA will be unreachable. >>>>      > >>>>      > >>>>      >   This should be no different than the UPDATE with SDP >>>> collision. >>>>     I am >>>>      > not sure what problem you are talking about. >>>>      > >>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>      >      >> RFC6141 says, if in doubt, send a refresh request to >>>> confirm. >>>>      >      > This is exactly the reason why handling of UPDATE >>>> transaction >>>>      >     collisions needs to be resolved. If session timer ends up >>>> in an >>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>     UA will >>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>     result in >>>>      >     a collision. >>>>      > >>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>     to avoid >>>>      >     collisions on retransmission. And we also need to decide >>>> how UAs >>>>      >     detect collisions. >>>>      > >>>>      > >>>>      > I am not sure what you are talking about. >>>>      > _____________ >>>>      > Roman Shpount >>>> >>> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Jun 27 15:17:42 2020 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 30EF93A083B for ; Sat, 27 Jun 2020 15:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 W87Sh85iZpMF for ; Sat, 27 Jun 2020 15:17:38 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::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 B415C3A083A for ; Sat, 27 Jun 2020 15:17:38 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id s21so11213430oic.9 for ; Sat, 27 Jun 2020 15:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hYZRlkC0qF2mM5QznuYFbeWVgJLXzVRa4f03eVX1vYo=; b=SkjbXVnAz1E94vchj91b1/zxPFwPR5qYysXRdkFrD82kmMzYwhqvoG59OAacNjjjL4 MQfwfigWl+q9+qF1IsInlrS5HkwCWau7+/5QHXo1Qa0Gls+zJvuL7zOMmkrcjmSOGH0L 1QUfBZoSZ3JE85wGO2jF1cRlteAg2OAQ9l3KdVBtoyntceQtn74epGVnyd0ntlHjmwrl XmGcNPIE3ch1rbc4xKSs6Wa6yEjeqRSCScpUvigLf5h4T3iuclc6Cy6RHsk4SkErpIxz CWvQQbTq2WHdXIuPbnt4ZvkeVisb8CYVwVJSqYRfXoVcoyppk+hGKtjpZiY2eXhceKDO R/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hYZRlkC0qF2mM5QznuYFbeWVgJLXzVRa4f03eVX1vYo=; b=avappeb4WXEVecvIt3a6sJemZVNGdOx9Mzwu54vIRO1xqy2wT18vi7dXMpMwHmf7+G Z1JQnzguRIqFgm4VICafMM5GXsOLsnmndWCy/oHuatFwWDQcSMMop6hK3sOxWoJGKCfu DAE+EAkHpMWGp5PaoH/Ybzdo7LU/oReUjG7kh5sejc20Kh2VER3Qn9NQgy4Zh7mtGlrL qDBfxLEFaJ0k09VAhSnLLBYxxkG5VtTDPKwhzwk74MiyF9AGGB1Pf/ZmhaYx4uZOot7r BZCgidGZwPVA5jcuGppEPBBXi9mHjxcKOsxz8u7R6v3Tv9UddyUiolKPGT+RYFPiFUw0 NQuw== X-Gm-Message-State: AOAM532xmwnAQvv2v/A6KUiLp/FMAxwr8aA5hKKPGLYqi8EenCVXE7e9 LW5rkQC899eauisxGwDL864JGhEBytU= X-Google-Smtp-Source: ABdhPJzsb/dKjUqPNFJDpSqDtJgUYxn+BirUuT0rphqagkCg1Ha5bLWknY8m7iazTWsXhbSxDtzYnA== X-Received: by 2002:aca:438a:: with SMTP id q132mr6955769oia.44.1593296257278; Sat, 27 Jun 2020 15:17:37 -0700 (PDT) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com. [209.85.210.52]) by smtp.gmail.com with ESMTPSA id r10sm7597742ooh.20.2020.06.27.15.17.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2020 15:17:36 -0700 (PDT) Received: by mail-ot1-f52.google.com with SMTP id 18so12023488otv.6 for ; Sat, 27 Jun 2020 15:17:35 -0700 (PDT) X-Received: by 2002:a4a:2459:: with SMTP id v25mr8163015oov.75.1593296255231; Sat, 27 Jun 2020 15:17:35 -0700 (PDT) MIME-Version: 1.0 References: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> In-Reply-To: <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> From: Roman Shpount Date: Sat, 27 Jun 2020 18:17:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000050abf305a918318d" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:17:41 -0000 --00000000000050abf305a918318d Content-Type: text/plain; charset="UTF-8" I agree on the option tag. It would be helpful to identify UAs which support the new draft during interop and troubleshooting network issues. This being said, I do not think we need to worry about UA which would not handle 491 responses to UPDATE properly. We only expand when 491 repose is generated. Handling 491 response is already a SHOULD in https://tools.ietf.org/html/rfc3311#section-5.3 regardless of the presence of the offer in the original UPDATE message. Best Regards, _____________ Roman Shpount On Sat, Jun 27, 2020 at 2:38 PM Paul Kyzivat wrote: > Some further thoughts on this... > > On 6/27/20 11:45 AM, Paul Kyzivat wrote: > > On 6/27/20 7:02 AM, OKUMURA Shinji wrote: > >> Hi Paul, > >> > >> All I want to confirm is one point. If a UA receives a session refresh > >> request during another session refresh transaction, the UA MUST reject > >> it with a 491 response, or MAY reject it with a 491 response. > > > > If we want to follow the precedent of O/A glare, then I think it is MUST > > reject. > > > >> A UA accepts both requests, compares two results, (if necessary) sends > >> additional request for confirmation. I don't have to worry that my > >> desired implementation is a protocol violation, right? > > > > I'm sure there are situations where the two ends can arrive at a common > > understanding without raising the 491. But I think the complexity of > > spelling out the cases so things are deterministic is not worth the > > added effort and resulting complexity in the spec. > > I subsequently realized that if we specify the use of 491 for ST then we > must consider what happens in cases of interop with an older > implementation that doesn't do that. > > If we have one UA supporting the extension and one that doesn't we first > will have to decide whether to use an option tag so the two can know who > does and doesn't support them. If so, then the 491 would not be used by > either end in ST glare cases, and everything would work as currently. > > If no option tag is used, then the UA that supports it may send a 491 to > indicate glare, but the other end won't, and also won't know precisely > what to do when receiving one. We will then have to figure out what the > end that does support the extension can do to fix things as best it can. > > In that case, it may be ok to allow the use of 491 to be optional, with > the alternative being to proceed as if the other end doesn't support the > extension. > > I think this probably suggests that an option tag for support of the > updated ST draft would be helpful. > > > Thanks, > > Paul > > > >> Regards, > >> Shinji > >> > >> On 2020/06/26 4:24, Paul Kyzivat wrote: > >>> Roman, > >>> > >>> On 6/25/20 2:20 PM, Roman Shpount wrote: > >>>> Hi Paul, > >>>> > >>>> First of all, the issue with target refresh that Shinjit was raising > >>>> is not new. It affects session description updates as much as it > >>>> does session timers. > >>>> > >>>> Second, I am not sure there is an actual problem. Target refresh is > >>>> done via a SIP transaction, so it does not happen instantaneously. > >>>> SIP transactions can be delayed due to proxy processing or network > >>>> delays, as well as due to a packet loss. The delay introduced by 491 > >>>> error response is generally comparable to transaction delay, so it > >>>> normally does not introduce any new problems. All that should happen > >>>> due to a 491 response, is that the transaction should be retried > >>>> with some delay and target refresh should happen slightly later. > >>>> > >>>> Considering that this is an existing design consideration which is > >>>> not specific to SIP session timer, I do not think it warrants a > >>>> discussion in the session timer document. > >>> > >>> My text was mostly just me explaining my reasoning for purposes of > >>> the discussion. I'm inclined to agree that it doesn't need to be > >>> discussed in the ST draft. It is not a new concern as far as whether > >>> to use 491 to resolve ST glare. > >>> > >>> I have a feeling we are all in agreement that the notion of glare > >>> during session timer refresh is a real thing, and that extending the > >>> use of 491 to apply to that situation is appropriate. > >>> > >>> It isn't strictly backward compatible. But if a UAS uses it, I bet > >>> there is a pretty good chance that a UAC receiving the 491 in that > >>> context will do the right thing, or at least something reasonable, > >>> even if it hasn't been updated for this change. Worst case is for the > >>> call to fail. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Best Regards, > >>>> _____________ > >>>> Roman Shpount > >>>> > >>>> > >>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat >>>> > wrote: > >>>> > >>>> ISTM that the key issue Shinji is raising is that it could be > >>>> problematic to raise an error to an UPDATE that is doing a target > >>>> refresh. This is true regardless of what else the UPDATE is > >>>> doing - an > >>>> offer, session timer refresh, or maybe nothing else. > >>>> > >>>> The bottom line here is that if you have an urgent need to do a > >>>> target > >>>> refresh, you should do it with a request that has little to no > >>>> chance of > >>>> being rejected. > >>>> > >>>> This is of course under the control of the UAC. If the UAC chooses > >>>> to do > >>>> a target refresh with an UPDATE, and in conjunction with a > >>>> session time > >>>> refresh (and/or offer) then it should be prepared for the > >>>> consequences > >>>> if the UPDATE is rejected (with 491 or anything else.) > >>>> > >>>> I guess we could discuss how much (if any) of this logic ought > >>>> to be > >>>> included in the document. > >>>> > >>>> I don't think this alters the validity of using 491 for a > >>>> session timer > >>>> glare situation. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 6/24/20 3:19 PM, Roman Shpount wrote: > >>>> > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji > >>>> > >>>> > >>>> >> wrote: > >>>> > > >>>> > >> 1. Handling of UPDATE with no SDP glare > >>>> > >> I'm not going to deny the solution with the 491 > >>>> response, > >>>> but I > >>>> > think it has a big impact. > >>>> > > > >>>> > > The situation with session timers is different from > >>>> target > >>>> > refresh. Target refresh is updated for each UA > >>>> independently. > >>>> > Session timer is negotiated for the entire session, so more > >>>> > collision scenarios are possible. One of such scenarios is > >>>> both UA > >>>> > sending UPDATE at the same time. If these UPDATE requests > >>>> do not > >>>> > carry SDP, currently they should be accepted. Resulting > >>>> session > >>>> > timer state is ambiguous. The only reliable way to prevent > >>>> ambiguous > >>>> > session timer state in this case is to refuse the UPDATE > >>>> message, > >>>> > similar to the session description collision. This is why > >>>> 491 was > >>>> > suggested. > >>>> > > >>>> > First of all, is a 491 rejected solution planned for bis? > >>>> > > >>>> > > >>>> > It was discussed but nothing is final. > >>>> > > >>>> > If so, the UPDATE for target-refresh and the one for > >>>> session-refresh > >>>> > are combined, as such they affect each other. And I think > >>>> the > >>>> result > >>>> > will be rarely ambiguous, if there is no change in the > >>>> session timer > >>>> > policy of each entity(UAC, proxies and UAS). Even so, > >>>> should UAs > >>>> > reject the UPDATE request? If the UPDATE with new > >>>> remote-target-uri > >>>> > is rejected, the UA will be unreachable. > >>>> > > >>>> > > >>>> > This should be no different than the UPDATE with SDP > >>>> collision. > >>>> I am > >>>> > not sure what problem you are talking about. > >>>> > > >>>> > >> 2. Handling of UPDATE transactions during initial > INVITE > >>>> > >> RFC6141 says, if in doubt, send a refresh request to > >>>> confirm. > >>>> > > This is exactly the reason why handling of UPDATE > >>>> transaction > >>>> > collisions needs to be resolved. If session timer ends up > >>>> in an > >>>> > ambiguous state, it is likely ambiguous for both UA and > both > >>>> UA will > >>>> > initiate an UPDATE refresh request to confirm, which will > >>>> result in > >>>> > a collision. > >>>> > > >>>> > I suggest the method in RFC3261 Section 14.1 as a procedure > >>>> to avoid > >>>> > collisions on retransmission. And we also need to decide > >>>> how UAs > >>>> > detect collisions. > >>>> > > >>>> > > >>>> > I am not sure what you are talking about. > >>>> > _____________ > >>>> > Roman Shpount > >>>> > >>> > > > > _______________________________________________ > > 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 > --00000000000050abf305a918318d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree on the option tag. It would be helpful to identify= UAs which support the new draft during interop and troubleshooting network= issues.=C2=A0

This being said, I do not think we need t= o worry about UA which would not handle 491 responses to UPDATE properly.= =20 We only expand when 491 repose is generated.=C2=A0 Handling 491 response is= already a SHOULD in=C2=A0https://tools.ietf.org/html/rfc3311#section-5.3=C2=A0regardl= ess of the presence=C2=A0of the offer in the original UPDATE message.=C2=A0=

Best Regards,
__________= ___
Roman Shpount


On Sat, Jun 27, 2020 at 2:38 PM P= aul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Some further thoughts on this...

On 6/27/20 11:45 AM, Paul Kyzivat wrote:
> On 6/27/20 7:02 AM, OKUMURA Shinji wrote:
>> Hi Paul,
>>
>> All I want to confirm is one point. If a UA receives a session ref= resh
>> request during another session refresh transaction, the UA MUST re= ject
>> it with a 491 response, or MAY reject it with a 491 response.
>
> If we want to follow the precedent of O/A glare, then I think it is MU= ST
> reject.
>
>> A UA accepts both requests, compares two results, (if necessary) s= ends
>> additional request for confirmation. I don't have to worry tha= t my
>> desired implementation is a protocol violation, right?
>
> I'm sure there are situations where the two ends can arrive at a c= ommon
> understanding without raising the 491. But I think the complexity of <= br> > spelling out the cases so things are deterministic is not worth the > added effort and resulting complexity in the spec.

I subsequently realized that if we specify the use of 491 for ST then we must consider what happens in cases of interop with an older
implementation that doesn't do that.

If we have one UA supporting the extension and one that doesn't we firs= t
will have to decide whether to use an option tag so the two can know who does and doesn't support them. If so, then the 491 would not be used by=
either end in ST glare cases, and everything would work as currently.

If no option tag is used, then the UA that supports it may send a 491 to indicate glare, but the other end won't, and also won't know precis= ely
what to do when receiving one. We will then have to figure out what the end that does support the extension can do to fix things as best it can.
In that case, it may be ok to allow the use of 491 to be optional, with the alternative being to proceed as if the other end doesn't support th= e
extension.

I think this probably suggests that an option tag for support of the
updated ST draft would be helpful.

>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Thanks,
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Paul
>
>> Regards,
>> Shinji
>>
>> On 2020/06/26 4:24, Paul Kyzivat wrote:
>>> Roman,
>>>
>>> On 6/25/20 2:20 PM, Roman Shpount wrote:
>>>> Hi Paul,
>>>>
>>>> First of all, the issue with target refresh that Shinjit w= as raising
>>>> is not new. It affects session description updates as much= as it
>>>> does session timers.
>>>>
>>>> Second, I am not sure there is an actual problem. Target r= efresh is
>>>> done via a SIP transaction, so it does not happen instanta= neously.
>>>> SIP transactions=C2=A0can be delayed due to proxy processi= ng or network
>>>> delays, as well as due to a packet loss. The delay introdu= ced by 491
>>>> error response is generally comparable to transaction dela= y, so it
>>>> normally does not introduce any new problems. All that sho= uld happen
>>>> due to a 491 response, is that the transaction should be r= etried
>>>> with some delay and target refresh should happen slightly = later.
>>>>
>>>> Considering that this is an existing design consideration = which is
>>>> not specific to SIP session timer, I do not think it warra= nts a
>>>> discussion in the session timer document.
>>>
>>> My text was mostly just me explaining my reasoning for purpose= s of
>>> the discussion. I'm inclined to agree that it doesn't = need to be
>>> discussed in the ST draft. It is not a new concern as far as w= hether
>>> to use 491 to resolve ST glare.
>>>
>>> I have a feeling we are all in agreement that the notion of gl= are
>>> during session timer refresh is a real thing, and that extendi= ng the
>>> use of 491 to apply to that situation is appropriate.
>>>
>>> It isn't strictly backward compatible. But if a UAS uses i= t, I bet
>>> there is a pretty good chance that a UAC receiving the 491 in = that
>>> context will do the right thing, or at least something reasona= ble,
>>> even if it hasn't been updated for this change. Worst case= is for the
>>> call to fail.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Thanks,
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Paul
>>>
>>>> Best Regards,
>>>> _____________
>>>> Roman Shpount
>>>>
>>>>
>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0 ISTM that the key issue Shinji is raisi= ng is that it could be
>>>> =C2=A0=C2=A0=C2=A0 problematic to raise an error to an UPD= ATE that is doing a target
>>>> =C2=A0=C2=A0=C2=A0 refresh. This is true regardless of wha= t else the UPDATE is
>>>> doing - an
>>>> =C2=A0=C2=A0=C2=A0 offer, session timer refresh, or maybe = nothing else.
>>>>
>>>> =C2=A0=C2=A0=C2=A0 The bottom line here is that if you hav= e an urgent need to do a
>>>> target
>>>> =C2=A0=C2=A0=C2=A0 refresh, you should do it with a reques= t that has little to no
>>>> =C2=A0=C2=A0=C2=A0 chance of
>>>> =C2=A0=C2=A0=C2=A0 being rejected.
>>>>
>>>> =C2=A0=C2=A0=C2=A0 This is of course under the control of = the UAC. If the UAC chooses
>>>> =C2=A0=C2=A0=C2=A0 to do
>>>> =C2=A0=C2=A0=C2=A0 a target refresh with an UPDATE, and in= conjunction with a
>>>> session time
>>>> =C2=A0=C2=A0=C2=A0 refresh (and/or offer) then it should b= e prepared for the
>>>> consequences
>>>> =C2=A0=C2=A0=C2=A0 if the UPDATE is rejected (with 491 or = anything else.)
>>>>
>>>> =C2=A0=C2=A0=C2=A0 I guess we could discuss how much (if a= ny) of this logic ought
>>>> to be
>>>> =C2=A0=C2=A0=C2=A0 included in the document.
>>>>
>>>> =C2=A0=C2=A0=C2=A0 I don't think this alters the valid= ity of using 491 for a
>>>> session timer
>>>> =C2=A0=C2=A0=C2=A0 glare situation.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank= s,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul<= br> >>>>
>>>> =C2=A0=C2=A0=C2=A0 On 6/24/20 3:19 PM, Roman Shpount wrote= :
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > On Wed, Jun 24, 2020 at 1:04= AM OKUMURA Shinji
>>>> =C2=A0=C2=A0=C2=A0 <ietf.shinji@gmail.com <mailto:ietf.shinji@gmail.com><= br> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:ietf.shinji@gmail.com
>>>> <mailto:ietf.shinji@gmail.com>>> wrote:
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>= 1. Handling of UPDATE with no SDP glare
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>= I'm not going to deny the solution with the 491
>>>> response,
>>>> =C2=A0=C2=A0=C2=A0 but I
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0think it = has a big impact.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 > The= situation with session timers is different from
>>>> target
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0refresh. = Target refresh is updated for each UA
>>>> independently.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0Session t= imer is negotiated for the entire=C2=A0session, so more
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0collision= =C2=A0scenarios are possible. One of such scenarios is
>>>> =C2=A0=C2=A0=C2=A0 both UA
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0sending U= PDATE at the same time. If these UPDATE=C2=A0requests
>>>> do not
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0carry SDP= , currently they should be accepted. Resulting
>>>> session
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0timer sta= te is ambiguous. The only reliable way to prevent
>>>> =C2=A0=C2=A0=C2=A0 ambiguous
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0session t= imer state in this case is to refuse the UPDATE
>>>> message,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0similar t= o the session description collision. This is why
>>>> 491 was
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0suggested= .
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0First of = all, is a 491 rejected solution planned for bis?
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > It was discussed but nothing= is final.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0If so, th= e UPDATE for target-refresh and the one for
>>>> =C2=A0=C2=A0=C2=A0 session-refresh
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0are combi= ned, as such they affect each other. And I think
>>>> the
>>>> =C2=A0=C2=A0=C2=A0 result
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0will be r= arely ambiguous, if there is no change in the
>>>> =C2=A0=C2=A0=C2=A0 session timer
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0policy of= each entity(UAC, proxies and UAS). Even so,
>>>> should UAs
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0reject th= e UPDATE request? If the UPDATE with new
>>>> =C2=A0=C2=A0=C2=A0 remote-target-uri
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0is reject= ed, the UA will be unreachable.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0This should be n= o different than the UPDATE with SDP
>>>> collision.
>>>> =C2=A0=C2=A0=C2=A0 I am
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > not sure what problem you ar= e talking about.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>= 2. Handling of UPDATE transactions during initial INVITE
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>= RFC6141 says, if in doubt, send a refresh request to
>>>> confirm.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Thi= s is exactly the reason why handling of UPDATE
>>>> transaction
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0collision= s needs to be resolved. If session timer ends up
>>>> in an
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0ambiguous= =C2=A0state, it is likely ambiguous for both UA and both
>>>> =C2=A0=C2=A0=C2=A0 UA will
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0initiate = an UPDATE refresh request to confirm, which will
>>>> =C2=A0=C2=A0=C2=A0 result in
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0a collisi= on.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0I suggest= the method in RFC3261 Section 14.1 as a procedure
>>>> =C2=A0=C2=A0=C2=A0 to avoid
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0collision= s on retransmission. And we also need to decide
>>>> how UAs
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 =C2=A0detect co= llisions.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > I am not sure what you are t= alking about.
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > _____________
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > Roman Shpount
>>>>
>>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore<= br>
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000050abf305a918318d-- From nobody Sat Jun 27 15:45:25 2020 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 7E7BB3A00B0 for ; Sat, 27 Jun 2020 15:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 f1w5LjQKbYlm for ; Sat, 27 Jun 2020 15:45:23 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 001853A00AE for ; Sat, 27 Jun 2020 15:45:22 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 64so12069382oti.5 for ; Sat, 27 Jun 2020 15:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U9YniV5k0LnHI8bddz5ivJrla4Qnnaf9rrQNsOAS21Q=; b=ilmjnaD58BQripwRr8JUudEzjkTN7GVRR7vg8dej79SyjNOJj7VWgHB8PwV9gzSgYK XwZ59AauK7wETCfe8V3FG+sOqjMLLQ9VCmjPbYoNUZtTY1odrDQmHbYwOCusJg5/XAM+ rgNOYK6Db5s8gAOmJKTnE3xUGweZ0M473Q9kbA+EanHu+ti3vDd4VCz5Lc1kY+hSZi+P joRo5Eq5RhgacWnnrmzaMOYtNZIetkJshMXMGz4R4JTBKIlThu5Xw6wqh7UZkS3uhUFw si5ou+IAu26TysBEptdYHrJ8MNqZDbXTEM6tiKAs5BPOnH3ANae2qI3QUiMtxnYGH4BA 2hRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U9YniV5k0LnHI8bddz5ivJrla4Qnnaf9rrQNsOAS21Q=; b=T0TKr5QMxkse+R69aZADxA2nQatYVVbV/OC6jKeW+FhyF7CbnkImTe9MiHex5cDiry r7blj+U8A6xpLKUy9tFq7Kw+/jqgWye1Dkawfy8wec9JvhRTsOcu7dwDTiujxZq9dxhG kfgaH7qWVBIymStFgszhvtrSuFEB/ajFmYvwm8D3FGU2WVDvbraBxTDmpQxxU/elDs61 d78/zLxtKx/fyQmO1SFiNvHpa2/pqJzXP2wpoT42TpLFG15ADW4FYTBcekVwUOrecRhX Fasa6z2agPJIvsvHpZPxUsrmOGK5hzJ+mf3Uhr/Xp3TZv3mxpkGOQNfnuD3WOu2pSRSQ 0DMA== X-Gm-Message-State: AOAM532pFfrB7eG1xHOotyKALXKf5K76IFg9tb1Hvd+eGfQzr33iMZTO /Ua0xo5ffpnQ4qaXSyEy8xth6T6mE3Y= X-Google-Smtp-Source: ABdhPJy6GqL5drcCc+mYYZ9g9XHsNHQaSK+rlog+48oE/k6Csjur4qjxkzzCb3kLgroSLIoUuPa3sQ== X-Received: by 2002:a9d:7dc1:: with SMTP id k1mr8072413otn.67.1593297921896; Sat, 27 Jun 2020 15:45:21 -0700 (PDT) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com. [209.85.210.51]) by smtp.gmail.com with ESMTPSA id v2sm7155899oib.26.2020.06.27.15.45.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2020 15:45:21 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id k15so12033327otp.8 for ; Sat, 27 Jun 2020 15:45:20 -0700 (PDT) X-Received: by 2002:a05:6830:1d1:: with SMTP id r17mr7797338ota.19.1593297920567; Sat, 27 Jun 2020 15:45:20 -0700 (PDT) MIME-Version: 1.0 References: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> In-Reply-To: <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> From: Roman Shpount Date: Sat, 27 Jun 2020 18:45:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000093ae0005a91894ad" Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:45:25 -0000 --00000000000093ae0005a91894ad Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 5:59 AM OKUMURA Shinji wrote: > Even if there is Session-Expires header, negotiation is always done. > And if the Min-SE header shows the maximum value in the dialog, then no > 422 response will occur. In other words, the Session-Expires header has > nothing to do with optimization. > Min-SE value for the dialog is generally not known (even though it can be cached from previous 422 responses). In any case, the intent of the current RFC is to keep session timer settings the same unless someone (proxy or UAS) needs to change them. > > 2. What SHOULD the value be equal to? > >> In general, the maximum of the Min-SE header field is not equal to the > >> current session interval. > >> It is ambiguous. In the first place, a UAC doesn't always know the exact > >> maximum. > > > > It is the maximum of Min-SE set by UAC and the current Session-Expires > > value for the dialog. UAC knows both. > > My question is whether the value set in the Session-Expires header is the > maximum of the Min-SE header field or the current session interval. > Probably this is an editorial error. > > Session-Expires is the maximum of the current session expires interval and Min-SE in the session timer refresh request. In general, unless you have a real problem to fix, I would not want to see anything changed. What you are proposing is a non-trivial change to the protocol. Unless it serves some purpose, I do not think we should do it. _____________ Roman Shpount --00000000000093ae0005a91894ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 27, 2020 at 5:59 AM OKUMURA S= hinji <ietf.shinji@gmail.com> wrote:
Even if there is Session-Expires header, negotiatio= n is always done.
And if the Min-SE header shows the maximum value in the dialog, then no 422= response will occur. In other words, the Session-Expires header has nothin= g to do with optimization.


=C2=A0
> 2. What SHOULD the = value be equal to?
>> In general, the maximum of the Min-SE header field is not equal to= the
>> current session interval.
>> It is ambiguous. In the first place, a UAC doesn't always know= the exact
>> maximum.
>
> It is the maximum of Min-SE set by UAC and the current Session-Expires=
> value for the dialog. UAC knows both.

My question is whether the value set in the Session-Expires header is the m= aximum of the Min-SE header field or the current session interval. Probably= this is an editorial error.

Session-Expires is th= e maximum of the current session expires interval and Min-SE in the session= timer refresh request.

In general, unless you hav= e a real problem to fix, I would not want to see anything changed. What you= are proposing is a non-trivial change to the protocol. Unless it serves so= me purpose, I do not think we should do it.
_____________
Roman Shpount=C2=A0=
--00000000000093ae0005a91894ad-- From nobody Sat Jun 27 16:51:10 2020 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 913513A086B for ; Sat, 27 Jun 2020 16:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 idIJaB4PpNhC for ; Sat, 27 Jun 2020 16:51:04 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2055.outbound.protection.outlook.com [40.107.237.55]) (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 CDE413A086A for ; Sat, 27 Jun 2020 16:51:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nK2KeVxjIl8FwGkDLvLE9dKu4ZBAl7iVrQjwrcve1Bwx3hbo0Rfaz00YqruU+7rAp13Vxf77NnC0umwrfu+CiUqTzbI2pUoZ7mYmbjCyZb8GsIi5xthne0k9c+jHA7hSfU4gPYEJzfJUq0d7Tets5GVfPqQMScojF6tPZ587C7ikBw0B9YBtM0tXlNZYOgnoZ3pLUvzwpKdw31XE4V+gFvChgfFgz0XSk1shyxUbfx5/MzK9LBG3U9wzZJ9meZ5tqKBz6h1oFzSoJ72ZipKp5sG71FHTxGpNaERfGAH0qby86EiwrTReo7ew9RZSzroEguHKx/+6f1M8oCZXKvk3qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Av7Oetd86tDxL4UAXpFAMO+VKFiNaOBaTUZevqr91A=; b=ajJjtHcv0/s5RhURPlO2hxwylCdopbUFCmQrbVTXXBNgoxJhfCa14y9JTGTJj2W6BtFrZfGnNpCNxkf5HwiWPDEg6oqlTSS71Qv/VMAfFpUNxudmsCV3prdaAQ0YaMsyqrUkS+EG2qxZw2N0kCFOglOh2t2008p/h9D6yFqHi+A5mYj3yhev4qAej5w/IUzHRejBOxrteXUzb3BeuBPecIltNhLWcuayHWVicOTnkIlXX3+5zSdXRo9uE9HZrV1qx4NGuOAwx9pGabFRmdxxWksdvofahQdb5UkF7tw5T/tCOYNTrJouYRgi3iay9+aLpSqQN9mkAEzkgVswPJd18g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Av7Oetd86tDxL4UAXpFAMO+VKFiNaOBaTUZevqr91A=; b=D92o5kbjGWUho2iogGg9dbmVCXzjwl4weNsJomxR1LTfVBGNoOMIz7hKP/uZUwCL5aDEcjarS7BQuBE4GB8Kp/uFmD1+7CZeThyrQHLFpJPwUFVzeYUjQr6wEHiYZj+X0ocyMPCK8rbLgRP16+4kR3KuZ0NwRvACGzKqZawf/Bk= Received: from BL0PR02CA0056.namprd02.prod.outlook.com (2603:10b6:207:3d::33) by CH2PR12MB3784.namprd12.prod.outlook.com (2603:10b6:610:21::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Sat, 27 Jun 2020 23:51:01 +0000 Received: from BL2NAM02FT044.eop-nam02.prod.protection.outlook.com (2603:10b6:207:3d:cafe::34) by BL0PR02CA0056.outlook.office365.com (2603:10b6:207:3d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Sat, 27 Jun 2020 23:51:01 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT044.mail.protection.outlook.com (10.152.77.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Sat, 27 Jun 2020 23:51:01 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05RNoxkg001144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 27 Jun 2020 19:51:00 -0400 To: sipcore@ietf.org References: <444b89aa-6ef4-74c1-830e-8b88438eccb4@gmail.com> <35d7c7d7-87a3-a0dd-819f-76b25d044804@gmail.com> From: Paul Kyzivat Message-ID: <95517954-60c7-2ad8-b9fe-2b49599acf09@alum.mit.edu> Date: Sat, 27 Jun 2020 19:50:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(396003)(136003)(39860400002)(346002)(376002)(46966005)(86362001)(82310400002)(356005)(478600001)(75432002)(31686004)(31696002)(82740400003)(7596003)(47076004)(26005)(186003)(336012)(966005)(53546011)(83380400001)(5660300002)(2906002)(8676002)(70206006)(6916009)(8936002)(70586007)(36906005)(786003)(316002)(2616005)(956004)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 51c7a4ff-70a9-4180-407d-08d81af4f23e X-MS-TrafficTypeDiagnostic: CH2PR12MB3784: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0447DB1C71 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NfoJJ+s8V04HVHe8iSPrDd/O/az4Y+/lVBnSsLmrq5+TJJdOLFBkC8Zagh/kPIRT0aMQBnRCjJQymFifC7GJNdHYpeUQ1j4aGxm3GLYhSuYG4xuaafbodCWAYyWFnHWxCx9A4IB/SrvW7fBy2XtQo8DJn39b2ZuygsTWXMlpKX6WOh0sJ1uTr6I8zbIgK0Pqff2OR4JsNvVNfE6a48zI3ytwM49H9JERU4uvGMGzh1zd2yRbhd3No6solMhZelnClnS07+4kNNwjRqS5Gr1mfmaS91IMdjx0P9zWA6MlktHXHlMUpEZ4sU+TuDKiUbyo2TE1CbP8IURVWbfdFnTMCo38ZhQ1Gq8NKL4lSL8sanOfzk8GDS9a8ahQ0aBxh8efT60cePijIFpB57tauYAJCyJYdXqf7st5uGzSkzFsttXkoMGdN75HQXTP3AiWpIgKqsQVPxcfMEIKjVvDf7/TGaH6a9mJUW30+dAbzbnySjsEDXgP0efXsDsZKlm+cOgR X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2020 23:51:01.0833 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 51c7a4ff-70a9-4180-407d-08d81af4f23e X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3784 Archived-At: Subject: Re: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:51:09 -0000 On 6/27/20 6:45 PM, Roman Shpount wrote: > On Sat, Jun 27, 2020 at 5:59 AM OKUMURA Shinji > wrote: > > Even if there is Session-Expires header, negotiation is always done. > And if the Min-SE header shows the maximum value in the dialog, then > no 422 response will occur. In other words, the Session-Expires > header has nothing to do with optimization. > > > Min-SE value for the dialog is generally not known (even though it can > be cached from previous 422 responses). This reminds me, one thing I always felt was lacking in 4028 is an explicit statement that adds SessionTimer state to the dialog state. Thanks, Paul > In any case, the intent of the current RFC is to keep session timer > settings the same unless someone (proxy or UAS) needs to change them. > > > 2. What SHOULD the value be equal to? > >> In general, the maximum of the Min-SE header field is not equal > to the > >> current session interval. > >> It is ambiguous. In the first place, a UAC doesn't always know > the exact > >> maximum. > > > > It is the maximum of Min-SE set by UAC and the current > Session-Expires > > value for the dialog. UAC knows both. > > My question is whether the value set in the Session-Expires header > is the maximum of the Min-SE header field or the current session > interval. Probably this is an editorial error. > > Session-Expires is the maximum of the current session expires interval > and Min-SE in the session timer refresh request. > > In general, unless you have a real problem to fix, I would not want to > see anything changed. What you are proposing is a non-trivial change to > the protocol. Unless it serves some purpose, I do not think we should do it. > _____________ > Roman Shpount > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 29 04:09:43 2020 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 A91A83A0DCD; Mon, 29 Jun 2020 04:09:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.5.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <159342897656.28787.11888459138259119790@ietfa.amsl.com> Date: Mon, 29 Jun 2020 04:09:36 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 11:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Authors : Christer Holmberg Steve Donovan Jonathan Rosenberg Filename : draft-ietf-sipcore-rfc4028bis-03.txt Pages : 26 Date : 2020-06-29 Abstract: This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 29 04:11:43 2020 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 7F9E13A0DCC for ; Mon, 29 Jun 2020 04:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 klhrNbq86mZB for ; Mon, 29 Jun 2020 04:11:39 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2043.outbound.protection.outlook.com [40.107.22.43]) (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 0509E3A0D21 for ; Mon, 29 Jun 2020 04:11:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJ6hq+HwuYmqBZX1oI3ZfsrHSEA9FjofmgKRhfB6NNAjg6sYohpjL7VzrwrLusp1LnPNfYaTx+Q7rZ3UI5TUUUZgZQvHKUAluoyf//lNQlN3oG//oirz9+ZPGOH7U7ZMofOtvZOayuLPoFHBACjknFZOxf7v2102ghJ3PsYs+aGz6pf9CUZcKBllVA28oc24ZlJyOwQuXZ1OuaSAoHDrbfuiJLjylNgoSB7L8sCOCbu4l/lDGLCGHYv4xvNoRZKAGxlsYuBXcABGg5PsxuRUQffFiRh3B9Vf2o+qAbUFLlGJQiTXandWMMQO2iOjYhv6n4LnHzkDPNr48kiRMXqSvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=paEFFJLA/fG/h7Hlum69sL+jUzlQ8WeK3EowP5Vni18=; b=G3lyZkm13xAU090donIEPeXmXibK44D2FiKND2dk5rK6DTtO3nUQZxybmTlmfBYTuzbAgkXXY7JfreDCeM5uEmuQdo0vSC3RZoNVpEMQpuNl32Pxp/71s9FK+a7+0a6tDynVUnrzbGX+Pwn11h4+Z/sMeFe1ylZAE0IK75jC9vnvbkjYSXACJbHq/k0j/3DbQx7vZhDr0YbQfwm5TnDIMfIcIlyQ6QJo5UX88fEF8+ZqKu0FPBl7sQG648n93vIF6yjZb4znG+umOPE1TxXdlXb4+PFkHjvL3vJVpOK89Y8JA++cGb/KJNRmPi8O+otWzNshfmqL0ehbY+ukK+rjfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=paEFFJLA/fG/h7Hlum69sL+jUzlQ8WeK3EowP5Vni18=; b=M+DnDGVEf/fllWZLAlYjA0S5VVO2uyrMrGhm/L1ANOHCgiRdMTUfawPM53PwdG2FjJwW3knMcdsTH1/rXcTlL/GrriVy5xDph4fc96X7hyV/pa3pfIAbUqZuAveRKJ3Qj272IdXcmQ6yfAr1iBgyq6H3O9+gU2TMx5gHswYDgiA= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.12; Mon, 29 Jun 2020 11:11:36 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3153.018; Mon, 29 Jun 2020 11:11:36 +0000 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: draft-ietf-sipcore-rfc4028bis-03 Thread-Index: AdZOBdrPffilJa5xQIq5GCvxoNhMQQ== Date: Mon, 29 Jun 2020 11:11:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d830d2bb-5667-46fa-87fb-08d81c1d30af x-ms-traffictypediagnostic: AM7PR07MB7012: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7T1A7ijDGtsMduPcCJzGzOq72KWOBsiw7EzimHFu0pQUC5l7m6EDwWhNixmXsnDanuvfjO8yEuRL/7WhF593pAQjogbxiluJN2ABJ7WHP7G7LtDayWgVbpxY8krXU80W7l2yOy+Sq+fEVhcN1WtpqC79y3WvjBVxFzzLb71MMTiJXMd+n80fk44YaivTYTDEfpf4yu/yipc3O1AnEMDGf06i71TxeQmKpr8C097j+ipOruYGeztPi4e/U4sqD+S3XWGOHDXP5yQsYo4Sgf5VknnMoute7PwsiESiB84UVJrXUcm2p+BtlfM7QO+p/DqHQzddjJHk69JLoR90kR1Svg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(55016002)(26005)(316002)(8676002)(83380400001)(6506007)(7696005)(478600001)(71200400001)(44832011)(8936002)(186003)(558084003)(9686003)(76116006)(66946007)(33656002)(2906002)(52536014)(64756008)(86362001)(6916009)(5660300002)(66556008)(66446008)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aOnUtjcWlMFn6gdKgTx0gSjh9XirOMIRK1ZHYXo5VIhr6y4FRZIjBxRnw376KymokJnb+MmhJkZFOvadcn8RiChas7Y5WWtaT+Ype995m6/ButyPM6SO6ibXz5pliYNh2ZwIfZOONXHcQPByKDsSiFT9i4f5iFoMdw+GzPGPIWCuIpPhi/3afw4m6bYDvJ3GduoDcmEl70BGQaXrDmQnQu1M6ruTF3bDLLcnoq3h5tGsBJmKh1S9aK1uiw11jr/qg8aqb5tKZDD0iLSUaa7tlexfwxXmhyN3xfaIMoL6K6Exi3vViW/YZ1QdxNnMsIDsRDotuedUxfxRvZlA7LjX26IDdAvi9dXVvKccMZ1WDm9qCVwVLn0mi/UBhsY5Zj5k5QTzNYKk6yqMRMZ9fPvd7wKVpcEP1dKVPdJHGQarbfyb6K0Md2jA5rp5+K1eyBtfD1ZcL34WNe+Usg2lAnL1+14Hz79ukZsmN4J1hfZE98Vf6dcLpr4tLeuylxh7VaVT x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB7012475541442AB871ADE1FE936E0AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB7012.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d830d2bb-5667-46fa-87fb-08d81c1d30af X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 11:11:36.8060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sMGvqXIbugiA1n6W01pW2Bwan47+eAfzKstEysvOwlYcBD8KNwqWm0Hp1wYD0e5s1YWn+8VyMxAEUvEMMmW976NvOphswV7sNWjje+WsspA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB7012 Archived-At: Subject: [sipcore] Draft new version: draft-ietf-sipcore-rfc4028bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 11:11:41 -0000 --_000_AM7PR07MB7012475541442AB871ADE1FE936E0AM7PR07MB7012eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version (-03) of draft-4028bis. The submission is due to expiration of the previous version. There are no c= hanges compared to the previous version. Due to vacation etc I will be off-radar for a couple of weeks. Regards, Christer --_000_AM7PR07MB7012475541442AB871ADE1FE936E0AM7PR07MB7012eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have submitted a new version = (-03) of draft-4028bis.

 

The submission is due to expira= tion of the previous version. There are no changes compared to the previous= version.

 

Due to vacation etc I will be o= ff-radar for a couple of weeks.

 

Regards,

 

Christer

--_000_AM7PR07MB7012475541442AB871ADE1FE936E0AM7PR07MB7012eurp_-- From nobody Mon Jun 29 04:53:35 2020 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 25A193A0E23 for ; Mon, 29 Jun 2020 04:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bKImK_Cuwm6 for ; Mon, 29 Jun 2020 04:53:31 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 84FFC3A0E1E for ; Mon, 29 Jun 2020 04:53:31 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id j1so7808582pfe.4 for ; Mon, 29 Jun 2020 04:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PbwPMG8/tJj/QTayfBz/KhQvoCu/2/1UApR56xUScjs=; b=WrA+jaGfWDBlP2bAUaFgooRCy1GM2FF/EoLjrvF+0JsEl5CNaPgjZESVvDhPGoVrLa L1BkdGpvPBHR2/fx/x21PVlz58rxxcLcpqkYaaDic23qjNci73oIB38axOJVlJA02Blx meeuj6rExNzFlLjZgtwmI2N6341UU4tletw4t17dEOk7xHEg5RdyDKGaoDcP6J4bIMhF pu+a/Ze0BM5e4JwXhS7QFyqL3VYppejIXFRivUy2wZziaIid0R+xIlA1V8vBFOprUDfH SWWuikFyC2miYSAFjzE480WSijx8PsNwN4WJRF0xLT5G145qosbbCR4L5gkfLzxr6xiV WnQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PbwPMG8/tJj/QTayfBz/KhQvoCu/2/1UApR56xUScjs=; b=eREz8ZlxkM3gexCjMCIuneOOBzt0oJplVnoXDejhTZb0OIGFQtNl5qOS1jfKmBao0I FIii4KVxR7YkxtubVfkfVeqoJ9IPUqMQovIu74tcbMI5udJtrlwWqGh6BErIKsGLbPqs 8S/X3x6+kOD3hQlAQu7U1ixkT0FR9tamoIlXmaOQhcj3D/NUiemjsNNsqo66ziucsPYY XWZAdG3csEH8AQyLcpX6PeUvNtKfbhCgWFqqdCctlYpbvlJicSO2KlhszAbqWviyoEDu 0PiNdNLLqFMRBowYPTO2+Xpn2bYTbT7LbFQuxcMrtch4lGqFiO3rAjVdjUOQQMnFwBzi 8I5g== X-Gm-Message-State: AOAM531YN1mdCUhDNg1e5W7Q7uSY57qmR5xhwepU2SE4H2gJAPg6NLpY LI36J6iVYpEaDTzX2yheMscGunqj X-Google-Smtp-Source: ABdhPJwv/9j5XzqLyEim1Pm8sSuAkbcjwZw3EQBEmtcuupR4AVc/OzarQVsHUwkC4f3l5s6FHYmk0Q== X-Received: by 2002:aa7:8651:: with SMTP id a17mr5926218pfo.48.1593431610842; Mon, 29 Jun 2020 04:53:30 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id z2sm5713192pff.36.2020.06.29.04.53.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 04:53:30 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE References: <95fad6b0-d621-6e00-7827-0f8a594ab75b@gmail.com> <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> Message-ID: Date: Mon, 29 Jun 2020 20:53:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200629-2, 2020/06/29), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 11:53:33 -0000 Hi Paul, > I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. I understand your suggestion. Probably my suggestion might be a bit more complicated than the 491 response. However, the 491 response may not be so simple. I think we need to differentiate from the 500 response. A B | | |INVITE | +->|--------------------->|<-+ Don't send INVITE | | | | Don't send INVITE Don't send UPDATE | | | | Don't send UPDATE 491 to INVITE | | | | 500 to INVITE 491 to UPDATE | | 2xx(offer)| | 500 to UPDATE +->|<---------------------|<-+ Don't send INVITE | | | | Don't send INVITE Don't send UPDATE | | | | Don't send UPDATE 491 to INVITE | | | | 500 to INVITE 491 to UPDATE | |ACK(answer) | | 500 to UPDATE +->|--------------------->|<-+ v | | v Regards, Shinji On 2020/06/28 0:45, Paul Kyzivat wrote: > On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >> Hi Paul, >> >> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. > > If we want to follow the precedent of O/A glare, then I think it is MUST reject. > >> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? > > I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. > >     Thanks, >     Paul > >> Regards, >> Shinji >> >> On 2020/06/26 4:24, Paul Kyzivat wrote: >>> Roman, >>> >>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>> Hi Paul, >>>> >>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >>>> >>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >>>> >>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. >>> >>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. >>> >>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. >>> >>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. >>> >>>      Thanks, >>>      Paul >>> >>>> Best Regards, >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >>>> >>>>     ISTM that the key issue Shinji is raising is that it could be >>>>     problematic to raise an error to an UPDATE that is doing a target >>>>     refresh. This is true regardless of what else the UPDATE is doing - an >>>>     offer, session timer refresh, or maybe nothing else. >>>> >>>>     The bottom line here is that if you have an urgent need to do a target >>>>     refresh, you should do it with a request that has little to no >>>>     chance of >>>>     being rejected. >>>> >>>>     This is of course under the control of the UAC. If the UAC chooses >>>>     to do >>>>     a target refresh with an UPDATE, and in conjunction with a session time >>>>     refresh (and/or offer) then it should be prepared for the consequences >>>>     if the UPDATE is rejected (with 491 or anything else.) >>>> >>>>     I guess we could discuss how much (if any) of this logic ought to be >>>>     included in the document. >>>> >>>>     I don't think this alters the validity of using 491 for a session timer >>>>     glare situation. >>>> >>>>              Thanks, >>>>              Paul >>>> >>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>     >>>>      > >> wrote: >>>>      > >>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>      >      >> I'm not going to deny the solution with the 491 response, >>>>     but I >>>>      >     think it has a big impact. >>>>      >      > >>>>      >      > The situation with session timers is different from target >>>>      >     refresh. Target refresh is updated for each UA independently. >>>>      >     Session timer is negotiated for the entire session, so more >>>>      >     collision scenarios are possible. One of such scenarios is >>>>     both UA >>>>      >     sending UPDATE at the same time. If these UPDATE requests do not >>>>      >     carry SDP, currently they should be accepted. Resulting session >>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>     ambiguous >>>>      >     session timer state in this case is to refuse the UPDATE message, >>>>      >     similar to the session description collision. This is why 491 was >>>>      >     suggested. >>>>      > >>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>      > >>>>      > >>>>      > It was discussed but nothing is final. >>>>      > >>>>      >     If so, the UPDATE for target-refresh and the one for >>>>     session-refresh >>>>      >     are combined, as such they affect each other. And I think the >>>>     result >>>>      >     will be rarely ambiguous, if there is no change in the >>>>     session timer >>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>>>      >     reject the UPDATE request? If the UPDATE with new >>>>     remote-target-uri >>>>      >     is rejected, the UA will be unreachable. >>>>      > >>>>      > >>>>      >   This should be no different than the UPDATE with SDP collision. >>>>     I am >>>>      > not sure what problem you are talking about. >>>>      > >>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>>>      >      > This is exactly the reason why handling of UPDATE transaction >>>>      >     collisions needs to be resolved. If session timer ends up in an >>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>     UA will >>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>     result in >>>>      >     a collision. >>>>      > >>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>     to avoid >>>>      >     collisions on retransmission. And we also need to decide how UAs >>>>      >     detect collisions. >>>>      > >>>>      > >>>>      > I am not sure what you are talking about. >>>>      > _____________ >>>>      > Roman Shpount >>>> >>> > From nobody Mon Jun 29 06:14:12 2020 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 789D33A0EC3 for ; Mon, 29 Jun 2020 06:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsWcKithPtOu for ; Mon, 29 Jun 2020 06:14:08 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 72A983A0EC2 for ; Mon, 29 Jun 2020 06:14:08 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id e18so8278361pgn.7 for ; Mon, 29 Jun 2020 06:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fJxSB1ffbWgPYJxK6PiTViXKxpNAaXC4W+feTX8smFM=; b=aE2X4E7t/a8H6PPeS2dgOn+esLSwF9aTOkTpncEhiKzix7Wlw0h+cYc5CMGbg2JVzk 4Q8NE3+/CouvxLUbMJnvSKj8f/hYC8Ybyi/6U94uMAljaENFxuzIdLQZXGl9Q9zitUTu S7v9ZDWYzMOyKKzSdGbBYM20a/8Qmx4ZMzu/nEwnglfiRnaHQ0v4ryPvvGLMQ+ZjQr6T BoxnLXjoWJkbDdoSR+OrgcJHo9tNNDPmrcce1hQU8Ue8A9FqNLFRAK0ATBK1cGIzq4kl 2WDvWBeEYc3sGOxqb+OclF030Eh+xFaBHF5qzlVq+zcgnyjfyH5qIA/JjCLqkEPyxri9 inIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fJxSB1ffbWgPYJxK6PiTViXKxpNAaXC4W+feTX8smFM=; b=rkoxaYXQcjNSU02lM34IWdVVs/N44v3leUFnFB9k/h4izUHkIwoDOqru5cNGqrXqLS /H2rcSSn+/ne3UdVaQgxnEoMN4I04dbjdi5ue0D8Ter2I4l2bXchtQzrdSEDKJwwQHP0 HRU1TTnDL62gPHFoUwHZ21Mm2g90fQWQIslFWIbvPJPP9cWdY0U30vpP/GHifEHEFHSM LYwjTe6zSJ5lFhCo/MdPytF6LWUstEag95RaQZ510b5zya8JgZ6VGlnSqQWZkQgTlub2 CFdpP9xfS/DGnCSs1KZs4drfaTkBOrD0Zdpe1Oo9sP9xM/cocN45lv2TdcMqs70SgQbI g3Ew== X-Gm-Message-State: AOAM5312PDjGvx1iOO+YPWWEB834Al4nyCCtTq4J5W1mM9BgGkF6DOuM YaNtNmsUepblSDT6d2DsrLk= X-Google-Smtp-Source: ABdhPJzT2HHN7y94g91v2Pj24srQ9TkjPLj35qRJcPrgCMxDC2O3ZJJloSveFIR8V6f8Ih9GLPeP4A== X-Received: by 2002:a65:46c9:: with SMTP id n9mr9855248pgr.89.1593436447704; Mon, 29 Jun 2020 06:14:07 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id t24sm29870742pgm.10.2020.06.29.06.14.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 06:14:07 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE References: <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> Message-ID: <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> Date: Mon, 29 Jun 2020 22:14:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200629-2, 2020/06/29), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:14:11 -0000 According to current regulations, UAs treat UPDATE with SDP as follows: A B | | |INVITE(offer) | +->|--------------------->|<-+ Don't send INVITE | | | | Don't send INVITE Don't send UPDATE | | | | Don't send UPDATE 491 to INVITE | | | | 500 to INVITE 491 to UPDATE | | 2xx(answer)| | 500 to UPDATE +->|<---------------------|<-+ may send INVITE | | | | may send INVITE may send UPDATE | | | | may send UPDATE may accept INVITE | | | | may accept INVITE may accept UPDATE | |ACK | | may accept UPDATE | |--------------------->| | v | | v A B | | |INVITE | +->|--------------------->|<-+ Don't send INVITE | | | | Don't send INVITE Don't send UPDATE | | | | Don't send UPDATE 491 to INVITE | | | | 500 to INVITE 491 to UPDATE | | 4xx| | 500 to UPDATE +->|<---------------------+<-+ | | | Don't send INVITE | | | may send UPDATE | | | may accept INVITE |ACK | | may accept UPDATE +->|---------> ------->|<-+ v | | v | | (4xx and ACK to it are atomic.) Regards, Shinji On 2020/06/29 20:53, OKUMURA Shinji wrote: > Hi Paul, > >> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. > > I understand your suggestion. Probably my suggestion might be a bit more complicated than the 491 response. > However, the 491 response may not be so simple. I think we need to differentiate from the 500 response. > >                       A                      B >                       |                      | >                       |INVITE                | >                    +->|--------------------->|<-+ > Don't send INVITE  |  |                      |  | Don't send INVITE > Don't send UPDATE  |  |                      |  | Don't send UPDATE > 491 to INVITE      |  |                      |  | 500 to INVITE > 491 to UPDATE      |  |            2xx(offer)|  | 500 to UPDATE >                    +->|<---------------------|<-+ > Don't send INVITE  |  |                      |  | Don't send INVITE > Don't send UPDATE  |  |                      |  | Don't send UPDATE > 491 to INVITE      |  |                      |  | 500 to INVITE > 491 to UPDATE      |  |ACK(answer)           |  | 500 to UPDATE >                    +->|--------------------->|<-+ >                    v  |                      |  v > > Regards, > Shinji > > On 2020/06/28 0:45, Paul Kyzivat wrote: >> On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >>> Hi Paul, >>> >>> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. >> >> If we want to follow the precedent of O/A glare, then I think it is MUST reject. >> >>> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? >> >> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. >> >>      Thanks, >>      Paul >> >>> Regards, >>> Shinji >>> >>> On 2020/06/26 4:24, Paul Kyzivat wrote: >>>> Roman, >>>> >>>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>>> Hi Paul, >>>>> >>>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >>>>> >>>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >>>>> >>>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. >>>> >>>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. >>>> >>>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. >>>> >>>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. >>>> >>>>      Thanks, >>>>      Paul >>>> >>>>> Best Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >>>>> >>>>>     ISTM that the key issue Shinji is raising is that it could be >>>>>     problematic to raise an error to an UPDATE that is doing a target >>>>>     refresh. This is true regardless of what else the UPDATE is doing - an >>>>>     offer, session timer refresh, or maybe nothing else. >>>>> >>>>>     The bottom line here is that if you have an urgent need to do a target >>>>>     refresh, you should do it with a request that has little to no >>>>>     chance of >>>>>     being rejected. >>>>> >>>>>     This is of course under the control of the UAC. If the UAC chooses >>>>>     to do >>>>>     a target refresh with an UPDATE, and in conjunction with a session time >>>>>     refresh (and/or offer) then it should be prepared for the consequences >>>>>     if the UPDATE is rejected (with 491 or anything else.) >>>>> >>>>>     I guess we could discuss how much (if any) of this logic ought to be >>>>>     included in the document. >>>>> >>>>>     I don't think this alters the validity of using 491 for a session timer >>>>>     glare situation. >>>>> >>>>>              Thanks, >>>>>              Paul >>>>> >>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>>     >>>>>      > >> wrote: >>>>>      > >>>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>>      >      >> I'm not going to deny the solution with the 491 response, >>>>>     but I >>>>>      >     think it has a big impact. >>>>>      >      > >>>>>      >      > The situation with session timers is different from target >>>>>      >     refresh. Target refresh is updated for each UA independently. >>>>>      >     Session timer is negotiated for the entire session, so more >>>>>      >     collision scenarios are possible. One of such scenarios is >>>>>     both UA >>>>>      >     sending UPDATE at the same time. If these UPDATE requests do not >>>>>      >     carry SDP, currently they should be accepted. Resulting session >>>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>>     ambiguous >>>>>      >     session timer state in this case is to refuse the UPDATE message, >>>>>      >     similar to the session description collision. This is why 491 was >>>>>      >     suggested. >>>>>      > >>>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>>      > >>>>>      > >>>>>      > It was discussed but nothing is final. >>>>>      > >>>>>      >     If so, the UPDATE for target-refresh and the one for >>>>>     session-refresh >>>>>      >     are combined, as such they affect each other. And I think the >>>>>     result >>>>>      >     will be rarely ambiguous, if there is no change in the >>>>>     session timer >>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>>>>      >     reject the UPDATE request? If the UPDATE with new >>>>>     remote-target-uri >>>>>      >     is rejected, the UA will be unreachable. >>>>>      > >>>>>      > >>>>>      >   This should be no different than the UPDATE with SDP collision. >>>>>     I am >>>>>      > not sure what problem you are talking about. >>>>>      > >>>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>>>>      >      > This is exactly the reason why handling of UPDATE transaction >>>>>      >     collisions needs to be resolved. If session timer ends up in an >>>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>>     UA will >>>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>>     result in >>>>>      >     a collision. >>>>>      > >>>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>>     to avoid >>>>>      >     collisions on retransmission. And we also need to decide how UAs >>>>>      >     detect collisions. >>>>>      > >>>>>      > >>>>>      > I am not sure what you are talking about. >>>>>      > _____________ >>>>>      > Roman Shpount >>>>> >>>> >> From nobody Mon Jun 29 12:53:39 2020 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 A5B193A07A3 for ; Mon, 29 Jun 2020 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 P3zN86vH_sYm for ; Mon, 29 Jun 2020 12:53:35 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750088.outbound.protection.outlook.com [40.107.75.88]) (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 1D7503A07A6 for ; Mon, 29 Jun 2020 12:53:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UQsJnLAqWJ/SZuHCFQvrWXmUDHJ+gkbRxC5GCsykehIz1kWOBga1/EQm//YSD72gsluVXEYbZuaTR1/ngEgn0gPc/64ZvjpRxFga8N7+P3JSUgFb+WgoigltvRHSF6NkFpZvI3/Ui0wxgDb19xqKH0u/4YNjf8ndfe4VJFKMgG2Q7OrW/YwxNCMVvyNulCGeVQo5CjE9guGsFJ5GfvB58wfcxQkmsEND+FVGRpv9oMnWSaYKV2QKqA8nkl74Qd74pvamVJQSf4OGtv775k5xfakacaJ2zscBlOVXLg95cxxr9t2UP39Ssw+zdgrqUf3DkFfaR2Ugl8nS+nIR3I9nBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2c9jj1Wnauu7BLKlM+FRMuaDxVUT+Y7+DQHsHA6QDg=; b=G+ijLi5a3kGJJVAjR9MBNq/fhY2XZZZfayhcRjErMdTaqtbFfqGs05ee0rwl+WjCzRgJu/QFhv02IZLIqCYh9ZKITFgkteQDOQxqitykdzZdT9Wo/gyH5qjbrRC16lHIlueIpDXVEWOEVOh/FyGinSRZ8LwiuKE1UmgMaEmaPvLTmx4UPXlk168irA32ArK5Eup7TOsUnr68fs4TmdWXFIldHfFM7ZnNJoQ6aLqycX33KSMklSJAnBYKft7lYbfSvItVYUinxRNa+cLI6sMjwaee7NOuXgmTxrXU2M0mC8I2nMjeE+pAv4TxMp7A1oCW5YJnybcbRkTdHKs95gUnDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2c9jj1Wnauu7BLKlM+FRMuaDxVUT+Y7+DQHsHA6QDg=; b=i221XPorXJ2UhC+1A7bW7h0hDc8kGhOVlBmnPKzZlDgqzEgT/xLenoH4PEesEHlaDBFNTdC0kMT7xRLOnGdEK7QjsgJFfMCkgUvGLhujrweYIDoPrxaCmqfwPtGxGG2Sl67cssRc2BoPVJLwka2aFMsNYxHyVcIzQA9uVR5Kizo= Received: from MN2PR11CA0026.namprd11.prod.outlook.com (2603:10b6:208:23b::31) by MN2PR12MB3837.namprd12.prod.outlook.com (2603:10b6:208:166::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Mon, 29 Jun 2020 19:53:29 +0000 Received: from BL2NAM02FT025.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23b:cafe::f6) by MN2PR11CA0026.outlook.office365.com (2603:10b6:208:23b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Mon, 29 Jun 2020 19:53:29 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT025.mail.protection.outlook.com (10.152.77.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Mon, 29 Jun 2020 19:53:28 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 05TJrQ5R010284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Jun 2020 15:53:27 -0400 To: OKUMURA Shinji , SIPCORE References: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> From: Paul Kyzivat Message-ID: <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> Date: Mon, 29 Jun 2020 15:53:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(376002)(346002)(396003)(39860400002)(46966005)(31696002)(47076004)(70586007)(70206006)(2616005)(956004)(30864003)(7596003)(110136005)(2906002)(31686004)(53546011)(186003)(8936002)(8676002)(5660300002)(82310400002)(356005)(83380400001)(82740400003)(336012)(478600001)(26005)(15650500001)(86362001)(36906005)(75432002)(786003)(316002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bfd0119c-2f94-43cc-76b0-08d81c6617eb X-MS-TrafficTypeDiagnostic: MN2PR12MB3837: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 044968D9E1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yzmwrMaKDyEO/EXC2M2WOGHRLYHpeMUzBYyVfqHcckLCFCLgGfvE6WunVTzDLDsZ7sAJGmn/K6ddCpDOF3AhOFkAjpNuDw7ZpUEhjwOsqIgOv0ZgRk9Av+UGL0U3NuyLnvze9Gz4dayyXR6vGjp8V0ifZGjiyn8JAS6JaiW9KnnWVg2961D9WpNpw26nZwHl8PK+ZwFrJDIKlE/brnGgUX4aezbtzg2so98owBRGwqevuoN8PvdOeIbaZfaz3da70eTLMuPATN0qYRl6Wm5IRwsb177K223DtpZai14HBtlOh4k1Bj6oDf6ZkuPvF7adBePxh31slsmOJme8gP7seWa34vpKB7XWoU0EV2ptc4UrkZZqJLNGVhOynCF8H+SdTyecclvJ61F+os9RekM5esfLwpmQelhUhmO9ofZrJhGZIoW01rKT4X57Gl4Ti5mU X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2020 19:53:28.5284 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bfd0119c-2f94-43cc-76b0-08d81c6617eb X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT025.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3837 Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:53:38 -0000 Shinji, IIUC you are suggesting to use the same rules for ST as for O/A. I don't think your diagrams are sufficient to describe the rules. They only talk about the types of messages, not the content of the messages. I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both. For one thing, in all of the messages that are being used for O/A it is actually the case that ST is being negotiated, even if only in the negative. An interesting odd case is if an INVITE is used to initiate an O/A, and then an UPDATE is used within it to negotiate ST but not carrying any SDP. Perhaps we should simply declare it is glare if there are overlapping INVITE or UPDATE in opposite directions regardless of what they contain. That would certainly simplify things. Thanks, Paul On 6/29/20 9:14 AM, OKUMURA Shinji wrote: > According to current regulations, UAs treat UPDATE with SDP as follows: > >                       A                      B >                       |                      | >                       |INVITE(offer)         | >                    +->|--------------------->|<-+ > Don't send INVITE  |  |                      |  | Don't send INVITE > Don't send UPDATE  |  |                      |  | Don't send UPDATE > 491 to INVITE      |  |                      |  | 500 to INVITE > 491 to UPDATE      |  |           2xx(answer)|  | 500 to UPDATE >                    +->|<---------------------|<-+ > may send INVITE    |  |                      |  | may send INVITE > may send UPDATE    |  |                      |  | may send UPDATE > may accept INVITE  |  |                      |  | may accept INVITE > may accept UPDATE  |  |ACK                   |  | may accept UPDATE >                    |  |--------------------->|  | >                    v  |                      |  v > > >                       A                      B >                       |                      | >                       |INVITE                | >                    +->|--------------------->|<-+ > Don't send INVITE  |  |                      |  | Don't send INVITE > Don't send UPDATE  |  |                      |  | Don't send UPDATE > 491 to INVITE      |  |                      |  | 500 to INVITE > 491 to UPDATE      |  |                   4xx|  | 500 to UPDATE >                    +->|<---------------------+<-+ >                       |                      |  | Don't send INVITE >                       |                      |  | may send UPDATE >                       |                      |  | may accept INVITE >                       |ACK                   |  | may accept UPDATE >                    +->|--------->    ------->|<-+ >                    v  |                      |  v >                       |                      | >        (4xx and ACK to it are atomic.) > > Regards, > Shinji > > On 2020/06/29 20:53, OKUMURA Shinji wrote: >> Hi Paul, >> >>> I'm sure there are situations where the two ends can arrive at a >>> common understanding without raising the 491. But I think the >>> complexity of spelling out the cases so things are deterministic is >>> not worth the added effort and resulting complexity in the spec. >> >> I understand your suggestion. Probably my suggestion might be a bit >> more complicated than the 491 response. >> However, the 491 response may not be so simple. I think we need to >> differentiate from the 500 response. >> >>                        A                      B >>                        |                      | >>                        |INVITE                | >>                     +->|--------------------->|<-+ >> Don't send INVITE  |  |                      |  | Don't send INVITE >> Don't send UPDATE  |  |                      |  | Don't send UPDATE >> 491 to INVITE      |  |                      |  | 500 to INVITE >> 491 to UPDATE      |  |            2xx(offer)|  | 500 to UPDATE >>                     +->|<---------------------|<-+ >> Don't send INVITE  |  |                      |  | Don't send INVITE >> Don't send UPDATE  |  |                      |  | Don't send UPDATE >> 491 to INVITE      |  |                      |  | 500 to INVITE >> 491 to UPDATE      |  |ACK(answer)           |  | 500 to UPDATE >>                     +->|--------------------->|<-+ >>                     v  |                      |  v >> >> Regards, >> Shinji >> >> On 2020/06/28 0:45, Paul Kyzivat wrote: >>> On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >>>> Hi Paul, >>>> >>>> All I want to confirm is one point. If a UA receives a session >>>> refresh request during another session refresh transaction, the UA >>>> MUST reject it with a 491 response, or MAY reject it with a 491 >>>> response. >>> >>> If we want to follow the precedent of O/A glare, then I think it is >>> MUST reject. >>> >>>> A UA accepts both requests, compares two results, (if necessary) >>>> sends additional request for confirmation. I don't have to worry >>>> that my desired implementation is a protocol violation, right? >>> >>> I'm sure there are situations where the two ends can arrive at a >>> common understanding without raising the 491. But I think the >>> complexity of spelling out the cases so things are deterministic is >>> not worth the added effort and resulting complexity in the spec. >>> >>>      Thanks, >>>      Paul >>> >>>> Regards, >>>> Shinji >>>> >>>> On 2020/06/26 4:24, Paul Kyzivat wrote: >>>>> Roman, >>>>> >>>>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>>>> Hi Paul, >>>>>> >>>>>> First of all, the issue with target refresh that Shinjit was >>>>>> raising is not new. It affects session description updates as much >>>>>> as it does session timers. >>>>>> >>>>>> Second, I am not sure there is an actual problem. Target refresh >>>>>> is done via a SIP transaction, so it does not happen >>>>>> instantaneously. SIP transactions can be delayed due to proxy >>>>>> processing or network delays, as well as due to a packet loss. The >>>>>> delay introduced by 491 error response is generally comparable to >>>>>> transaction delay, so it normally does not introduce any new >>>>>> problems. All that should happen due to a 491 response, is that >>>>>> the transaction should be retried with some delay and target >>>>>> refresh should happen slightly later. >>>>>> >>>>>> Considering that this is an existing design consideration which is >>>>>> not specific to SIP session timer, I do not think it warrants a >>>>>> discussion in the session timer document. >>>>> >>>>> My text was mostly just me explaining my reasoning for purposes of >>>>> the discussion. I'm inclined to agree that it doesn't need to be >>>>> discussed in the ST draft. It is not a new concern as far as >>>>> whether to use 491 to resolve ST glare. >>>>> >>>>> I have a feeling we are all in agreement that the notion of glare >>>>> during session timer refresh is a real thing, and that extending >>>>> the use of 491 to apply to that situation is appropriate. >>>>> >>>>> It isn't strictly backward compatible. But if a UAS uses it, I bet >>>>> there is a pretty good chance that a UAC receiving the 491 in that >>>>> context will do the right thing, or at least something reasonable, >>>>> even if it hasn't been updated for this change. Worst case is for >>>>> the call to fail. >>>>> >>>>>      Thanks, >>>>>      Paul >>>>> >>>>>> Best Regards, >>>>>> _____________ >>>>>> Roman Shpount >>>>>> >>>>>> >>>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat >>>>>> > wrote: >>>>>> >>>>>>     ISTM that the key issue Shinji is raising is that it could be >>>>>>     problematic to raise an error to an UPDATE that is doing a target >>>>>>     refresh. This is true regardless of what else the UPDATE is >>>>>> doing - an >>>>>>     offer, session timer refresh, or maybe nothing else. >>>>>> >>>>>>     The bottom line here is that if you have an urgent need to do >>>>>> a target >>>>>>     refresh, you should do it with a request that has little to no >>>>>>     chance of >>>>>>     being rejected. >>>>>> >>>>>>     This is of course under the control of the UAC. If the UAC >>>>>> chooses >>>>>>     to do >>>>>>     a target refresh with an UPDATE, and in conjunction with a >>>>>> session time >>>>>>     refresh (and/or offer) then it should be prepared for the >>>>>> consequences >>>>>>     if the UPDATE is rejected (with 491 or anything else.) >>>>>> >>>>>>     I guess we could discuss how much (if any) of this logic ought >>>>>> to be >>>>>>     included in the document. >>>>>> >>>>>>     I don't think this alters the validity of using 491 for a >>>>>> session timer >>>>>>     glare situation. >>>>>> >>>>>>              Thanks, >>>>>>              Paul >>>>>> >>>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>>>     >>>>>>      > >>>>> >> wrote: >>>>>>      > >>>>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>>>      >      >> I'm not going to deny the solution with the 491 >>>>>> response, >>>>>>     but I >>>>>>      >     think it has a big impact. >>>>>>      >      > >>>>>>      >      > The situation with session timers is different from >>>>>> target >>>>>>      >     refresh. Target refresh is updated for each UA >>>>>> independently. >>>>>>      >     Session timer is negotiated for the entire session, so >>>>>> more >>>>>>      >     collision scenarios are possible. One of such scenarios is >>>>>>     both UA >>>>>>      >     sending UPDATE at the same time. If these >>>>>> UPDATE requests do not >>>>>>      >     carry SDP, currently they should be accepted. Resulting >>>>>> session >>>>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>>>     ambiguous >>>>>>      >     session timer state in this case is to refuse the >>>>>> UPDATE message, >>>>>>      >     similar to the session description collision. This is >>>>>> why 491 was >>>>>>      >     suggested. >>>>>>      > >>>>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>>>      > >>>>>>      > >>>>>>      > It was discussed but nothing is final. >>>>>>      > >>>>>>      >     If so, the UPDATE for target-refresh and the one for >>>>>>     session-refresh >>>>>>      >     are combined, as such they affect each other. And I >>>>>> think the >>>>>>     result >>>>>>      >     will be rarely ambiguous, if there is no change in the >>>>>>     session timer >>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, >>>>>> should UAs >>>>>>      >     reject the UPDATE request? If the UPDATE with new >>>>>>     remote-target-uri >>>>>>      >     is rejected, the UA will be unreachable. >>>>>>      > >>>>>>      > >>>>>>      >   This should be no different than the UPDATE with SDP >>>>>> collision. >>>>>>     I am >>>>>>      > not sure what problem you are talking about. >>>>>>      > >>>>>>      >      >> 2. Handling of UPDATE transactions during initial >>>>>> INVITE >>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request >>>>>> to confirm. >>>>>>      >      > This is exactly the reason why handling of UPDATE >>>>>> transaction >>>>>>      >     collisions needs to be resolved. If session timer ends >>>>>> up in an >>>>>>      >     ambiguous state, it is likely ambiguous for both UA and >>>>>> both >>>>>>     UA will >>>>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>>>     result in >>>>>>      >     a collision. >>>>>>      > >>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a >>>>>> procedure >>>>>>     to avoid >>>>>>      >     collisions on retransmission. And we also need to >>>>>> decide how UAs >>>>>>      >     detect collisions. >>>>>>      > >>>>>>      > >>>>>>      > I am not sure what you are talking about. >>>>>>      > _____________ >>>>>>      > Roman Shpount >>>>>> >>>>> >>> From nobody Mon Jun 29 14:02:56 2020 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 7B7333A0C5F for ; Mon, 29 Jun 2020 14:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 bhB-R_VKGKgC for ; Mon, 29 Jun 2020 14:02:53 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 4641A3A0C47 for ; Mon, 29 Jun 2020 14:02:53 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id d4so16751698otk.2 for ; Mon, 29 Jun 2020 14:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=er10RzI67FJDeGQCdPtCtnA16jVmciCQGFe4AoA9SeM=; b=r9CnvPgO9SUOjRXwArrcWXSAzaeWjgWQSHaoJ/v7kHzE22hEDTaSBfGN3vflM3XqYa 3nF5TPlGcc5rvwlXy1/sA9UJlRzTIlXI5Bkx5UTtyQtB9lgNt4DaFmZvxqwvmfp9Ueij jL4Y5Uti88/pigzyEPCMxBZ0qQnBsrdsZP9h8utLlsrCJE9ZLnmpWYwF3y4guiUM+j2l nAoekFuLcXODqb4GU/+SMm7OY6itq2h6UPw93eXRB6hg88MWUcQOJUpBPjiw4nDskJi9 LrgLoPUVCeNxYR8adoZTzJR8BZccwzeLMcR8rsVikD6PAByek8fseqDgarhFOd3ebSas hnBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=er10RzI67FJDeGQCdPtCtnA16jVmciCQGFe4AoA9SeM=; b=XlmkLg7L/IYxYpuFrYO5u0yAFtiRZgh4z5c5o0fR/gYOu13jJtHo/IrjYTrrlYTfCK HRehJpR2mx1a6nwitrCob8c/3+il4H0x4v9rsxfvz7Sy13vCL1f5V2Kb7nzfMCq2CXcH 29E80r9jB+CcOb/gOlvyC2msyVxVkN8dBJcbTJHQdOWJlPjSSjjP3K715F6Yg9XtcH9R dSex6YcWQlm8HD5uHzjF1MbBi78I8ok12nd94E+RvmN5cOj5jKwoU4yYYXxzLifVjNi7 PVg7KAXOQllCq8fxmCdt59kfwCSdJrd9J4TNdaRsxMA1ZKYrorguOagP9YUXnXLJLam2 qveg== X-Gm-Message-State: AOAM532CN/V2xubSEWOuzyrkMYRCCSFjhmGtxp8Q0XNKSYdzd0k5UfXi Fh8ZnkmBngADaKpzr6Wv+vk2uCfvvsA= X-Google-Smtp-Source: ABdhPJw3+TnCLsMoKxP3zyN/IdcSh7y27g57mok6COC3KiFY4GCZOzz2wx1WbnXkBr2Q2kODQ86wIw== X-Received: by 2002:a05:6830:2368:: with SMTP id r8mr15290836oth.120.1593464571954; Mon, 29 Jun 2020 14:02:51 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com. [209.85.210.43]) by smtp.gmail.com with ESMTPSA id i22sm272306otj.27.2020.06.29.14.02.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 14:02:50 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id 18so16730247otv.6 for ; Mon, 29 Jun 2020 14:02:50 -0700 (PDT) X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr14467601otr.13.1593464569794; Mon, 29 Jun 2020 14:02:49 -0700 (PDT) MIME-Version: 1.0 References: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> In-Reply-To: <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> From: Roman Shpount Date: Mon, 29 Jun 2020 17:02:38 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: OKUMURA Shinji , SIPCORE Content-Type: multipart/alternative; boundary="000000000000a5160505a93f6191" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:02:55 -0000 --000000000000a5160505a93f6191 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 3:53 PM Paul Kyzivat wrote: > Perhaps we should simply declare it is glare if there are overlapping > INVITE or UPDATE in opposite directions regardless of what they contain. > That would certainly simplify things. > This will simplify things but break existing call scenarios. One of the use cases for UPDATE is to negotiate SDP during the early dialog. It should be possible to send an UPDATE with SDP after 183 response with SDP while the original INVITE transaction is still in progress. Best Regards, _____________ Roman Shpount --000000000000a5160505a93f6191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps we should simply declare it is glare if there= are overlapping
INVITE or UPDATE in opposite directions regardless of what they contain. That would certainly simplify things.

T= his will simplify things but break existing call scenarios. One of the use = cases for UPDATE is to negotiate=C2=A0SDP during the early dialog. It shoul= d be possible to send an UPDATE with SDP after 183 response with SDP while = the original INVITE transaction is still in progress.

<= div>Best Regards,
____= _________
Roman Shpount=C2=A0
--000000000000a5160505a93f6191-- From nobody Mon Jun 29 21:32:37 2020 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 546DE3A0AE2 for ; Mon, 29 Jun 2020 21:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp1IqMFYn4k1 for ; Mon, 29 Jun 2020 21:32:34 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 6E86A3A0ADC for ; Mon, 29 Jun 2020 21:32:34 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id x11so7956986plo.7 for ; Mon, 29 Jun 2020 21:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7cL+DytzmZO4bbEfWWhnDP5sN9kRi59kBUXr3gLNDQQ=; b=DNsts7sAegyxlk53vjSZKpLc+J+CCCnnA8vLqJMXTY4BM/063NnOD+fFLlBMP7eQ2z OW5tldt1Gb1BVPekP7Ej8909N3WCkfQtjBYxdcnoWYbPBwWQjxrNIq0uGQLKOnbbGt7u Fr8JUaNIBO0TUjmxhxPAEVNqNzXzmZXjGqXmIlb3hZ8jbV3roLuizraTVU/VAZGDSyuY BqdDtyF5vWKfYqnEwsZkpeAKhRZMhG4uGhd5dOTdEbFwmhFvPtbnveGHzLyBnjjbYELP hH2a1oFhDJmVeul3U8+l95wiagfe+W+C6BIu7+xcy9AIT18i8ypvYL3AQ9CQjiHbWOln IknQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7cL+DytzmZO4bbEfWWhnDP5sN9kRi59kBUXr3gLNDQQ=; b=gUOrOJJQXSOo9SHdjrVFuIhRDCzgEC3O/S6sFpoRkSEw4ySJOi2nsF4Wp98tkSiict 7sPLqnTKI8hnUjLAjXH5fLUkPCZqUuQzhsbSZEG0fWAgTX8m+XEjDAbQIL2TeGHhWXvg zjRsl6NAzLMXFtb8eDglLrjzqrdX7g9U+gPubYGaqya82vcScahnAESwW57nTl/THqwD uF+qtJAE0lT86wLiknrdvg2KetMzHdHLbYvgpnAKDoCI4K9sTI6mqxXVJKAz4lxsb0cT s38mYF71WBxlQjR7x2twGD6VmL4MpUoXAPqEdslPFN0V7Ydc6AMs2g2B67kZxDyxP915 X2GA== X-Gm-Message-State: AOAM533dvY29ZglFQ2CcSd3obt6XvCnrV69BQZxytlpBmVeceBecb0Zp kj9U591zjh5Oe2BzPOcXfxv45LSe X-Google-Smtp-Source: ABdhPJyETXvx2lw+BHckjsLLGgOMEvwV1DxgMOzGHicYA2jqyMZ/ZFQ5FPRJibOnhmEkI/OP5IXJaQ== X-Received: by 2002:a17:902:8e82:: with SMTP id bg2mr16534287plb.198.1593491553406; Mon, 29 Jun 2020 21:32:33 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id n37sm1135695pgl.82.2020.06.29.21.32.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 21:32:32 -0700 (PDT) To: Paul Kyzivat , SIPCORE References: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> From: OKUMURA Shinji Message-ID: <027a72cf-9fcb-20cc-2bfa-0821123c5522@gmail.com> Date: Tue, 30 Jun 2020 13:32:30 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 04:32:36 -0000 Hi Paul, My diagrams were drawn assuming there is no SDP in the UPDATE request. One of the issues is when the ST negotiation(initiated by INVITE) period ends. 20xx, 4xx or ACK? > I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both. I agree with you. But O/A rules are written based on offer and answer, not transactions, so it's not easy to make a unified set. And this rule is likely to be further complicated by the fact that the ST cannot handle 18x responses. Regards, Shinji On 2020/06/30 4:53, Paul Kyzivat wrote: > Shinji, > > IIUC you are suggesting to use the same rules for ST as for O/A. > > I don't think your diagrams are sufficient to describe the rules. They only talk about the types of messages, not the content of the messages. > > I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both. > > For one thing, in all of the messages that are being used for O/A it is actually the case that ST is being negotiated, even if only in the negative. > > An interesting odd case is if an INVITE is used to initiate an O/A, and then an UPDATE is used within it to negotiate ST but not carrying any SDP. > > Perhaps we should simply declare it is glare if there are overlapping INVITE or UPDATE in opposite directions regardless of what they contain. That would certainly simplify things. > >     Thanks, >     Paul > > On 6/29/20 9:14 AM, OKUMURA Shinji wrote: >> According to current regulations, UAs treat UPDATE with SDP as follows: >> >>                        A                      B >>                        |                      | >>                        |INVITE(offer)         | >>                     +->|--------------------->|<-+ >> Don't send INVITE  |  |                      |  | Don't send INVITE >> Don't send UPDATE  |  |                      |  | Don't send UPDATE >> 491 to INVITE      |  |                      |  | 500 to INVITE >> 491 to UPDATE      |  |           2xx(answer)|  | 500 to UPDATE >>                     +->|<---------------------|<-+ >> may send INVITE    |  |                      |  | may send INVITE >> may send UPDATE    |  |                      |  | may send UPDATE >> may accept INVITE  |  |                      |  | may accept INVITE >> may accept UPDATE  |  |ACK                   |  | may accept UPDATE >>                     |  |--------------------->|  | >>                     v  |                      |  v >> >> >>                        A                      B >>                        |                      | >>                        |INVITE                | >>                     +->|--------------------->|<-+ >> Don't send INVITE  |  |                      |  | Don't send INVITE >> Don't send UPDATE  |  |                      |  | Don't send UPDATE >> 491 to INVITE      |  |                      |  | 500 to INVITE >> 491 to UPDATE      |  |                   4xx|  | 500 to UPDATE >>                     +->|<---------------------+<-+ >>                        |                      |  | Don't send INVITE >>                        |                      |  | may send UPDATE >>                        |                      |  | may accept INVITE >>                        |ACK                   |  | may accept UPDATE >>                     +->|--------->    ------->|<-+ >>                     v  |                      |  v >>                        |                      | >>         (4xx and ACK to it are atomic.) >> >> Regards, >> Shinji >> >> On 2020/06/29 20:53, OKUMURA Shinji wrote: >>> Hi Paul, >>> >>>> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. >>> >>> I understand your suggestion. Probably my suggestion might be a bit more complicated than the 491 response. >>> However, the 491 response may not be so simple. I think we need to differentiate from the 500 response. >>> >>>                        A                      B >>>                        |                      | >>>                        |INVITE                | >>>                     +->|--------------------->|<-+ >>> Don't send INVITE  |  |                      |  | Don't send INVITE >>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>> 491 to INVITE      |  |                      |  | 500 to INVITE >>> 491 to UPDATE      |  |            2xx(offer)|  | 500 to UPDATE >>>                     +->|<---------------------|<-+ >>> Don't send INVITE  |  |                      |  | Don't send INVITE >>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>> 491 to INVITE      |  |                      |  | 500 to INVITE >>> 491 to UPDATE      |  |ACK(answer)           |  | 500 to UPDATE >>>                     +->|--------------------->|<-+ >>>                     v  |                      |  v >>> >>> Regards, >>> Shinji >>> >>> On 2020/06/28 0:45, Paul Kyzivat wrote: >>>> On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >>>>> Hi Paul, >>>>> >>>>> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. >>>> >>>> If we want to follow the precedent of O/A glare, then I think it is MUST reject. >>>> >>>>> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? >>>> >>>> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. >>>> >>>>      Thanks, >>>>      Paul >>>> >>>>> Regards, >>>>> Shinji >>>>> >>>>> On 2020/06/26 4:24, Paul Kyzivat wrote: >>>>>> Roman, >>>>>> >>>>>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>>>>> Hi Paul, >>>>>>> >>>>>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >>>>>>> >>>>>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >>>>>>> >>>>>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. >>>>>> >>>>>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. >>>>>> >>>>>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. >>>>>> >>>>>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. >>>>>> >>>>>>      Thanks, >>>>>>      Paul >>>>>> >>>>>>> Best Regards, >>>>>>> _____________ >>>>>>> Roman Shpount >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >>>>>>> >>>>>>>     ISTM that the key issue Shinji is raising is that it could be >>>>>>>     problematic to raise an error to an UPDATE that is doing a target >>>>>>>     refresh. This is true regardless of what else the UPDATE is doing - an >>>>>>>     offer, session timer refresh, or maybe nothing else. >>>>>>> >>>>>>>     The bottom line here is that if you have an urgent need to do a target >>>>>>>     refresh, you should do it with a request that has little to no >>>>>>>     chance of >>>>>>>     being rejected. >>>>>>> >>>>>>>     This is of course under the control of the UAC. If the UAC chooses >>>>>>>     to do >>>>>>>     a target refresh with an UPDATE, and in conjunction with a session time >>>>>>>     refresh (and/or offer) then it should be prepared for the consequences >>>>>>>     if the UPDATE is rejected (with 491 or anything else.) >>>>>>> >>>>>>>     I guess we could discuss how much (if any) of this logic ought to be >>>>>>>     included in the document. >>>>>>> >>>>>>>     I don't think this alters the validity of using 491 for a session timer >>>>>>>     glare situation. >>>>>>> >>>>>>>              Thanks, >>>>>>>              Paul >>>>>>> >>>>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>>>>     >>>>>>>      > >> wrote: >>>>>>>      > >>>>>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>>>>      >      >> I'm not going to deny the solution with the 491 response, >>>>>>>     but I >>>>>>>      >     think it has a big impact. >>>>>>>      >      > >>>>>>>      >      > The situation with session timers is different from target >>>>>>>      >     refresh. Target refresh is updated for each UA independently. >>>>>>>      >     Session timer is negotiated for the entire session, so more >>>>>>>      >     collision scenarios are possible. One of such scenarios is >>>>>>>     both UA >>>>>>>      >     sending UPDATE at the same time. If these UPDATE requests do not >>>>>>>      >     carry SDP, currently they should be accepted. Resulting session >>>>>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>>>>     ambiguous >>>>>>>      >     session timer state in this case is to refuse the UPDATE message, >>>>>>>      >     similar to the session description collision. This is why 491 was >>>>>>>      >     suggested. >>>>>>>      > >>>>>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>>>>      > >>>>>>>      > >>>>>>>      > It was discussed but nothing is final. >>>>>>>      > >>>>>>>      >     If so, the UPDATE for target-refresh and the one for >>>>>>>     session-refresh >>>>>>>      >     are combined, as such they affect each other. And I think the >>>>>>>     result >>>>>>>      >     will be rarely ambiguous, if there is no change in the >>>>>>>     session timer >>>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>>>>>>      >     reject the UPDATE request? If the UPDATE with new >>>>>>>     remote-target-uri >>>>>>>      >     is rejected, the UA will be unreachable. >>>>>>>      > >>>>>>>      > >>>>>>>      >   This should be no different than the UPDATE with SDP collision. >>>>>>>     I am >>>>>>>      > not sure what problem you are talking about. >>>>>>>      > >>>>>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>>>>>>      >      > This is exactly the reason why handling of UPDATE transaction >>>>>>>      >     collisions needs to be resolved. If session timer ends up in an >>>>>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>>>>     UA will >>>>>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>>>>     result in >>>>>>>      >     a collision. >>>>>>>      > >>>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>>>>     to avoid >>>>>>>      >     collisions on retransmission. And we also need to decide how UAs >>>>>>>      >     detect collisions. >>>>>>>      > >>>>>>>      > >>>>>>>      > I am not sure what you are talking about. >>>>>>>      > _____________ >>>>>>>      > Roman Shpount >>>>>>> >>>>>> >>>> > From nobody Tue Jun 30 02:30:14 2020 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 6B58A3A113C for ; Tue, 30 Jun 2020 02:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTLyyk2ECM0Q for ; Tue, 30 Jun 2020 02:30:11 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 703F83A113B for ; Tue, 30 Jun 2020 02:30:11 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id t6so9697213pgq.1 for ; Tue, 30 Jun 2020 02:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=ZDV1cheUfTzh13WCcen0QQNw9bFhg4csfQ066lalkiI=; b=MtenSZge4okONR3YXyJjBNELO/ycp/aEh49t7bsF09lXuol0IBsDzuV6dXg9djeXKp CsHTOtq8ERavnO74FRwbuf63MjuPwAuKMNg6j3ybMwlIavU7fqHR42AE86UdzIbHlxuS HaKo2p5pXNodOI2lHQfcl501XExLGXL94Y9E2P1iu+mLaN1qNatv0M1b/8QC18l/43go gRtEi8qkJ1IDm48zBj2MQsqWuqaqpXx8UH2gRyt4hjBagUDpHcBHlwfTWY/Civ11C0hc 5Kq/vgHOAm+NLdKTqbKaBvJwKFNB9RO5CbTOfM/CQPfQxo+YmJdm68LLgNpH4hq0CJt+ S8Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=ZDV1cheUfTzh13WCcen0QQNw9bFhg4csfQ066lalkiI=; b=J94LrlaGOxhZMtnkO/wsfjaXDeRBsA6HDfB3ZNZ8xk9v3zlkG9ARU0vCFX3xUsHgP5 M3eVku3WpeOl/n31veDIeoaPEG9h8IPHYT0djNsk7fxfdKXH8pennE8OVvhPqAaTnam6 PXmMj/nVGMm6Dp+8/XHJoKVD9OrhkiEijFmMd2twV66T/mMORfGDnmOPJKEs+xqayiJz 0NtdTuTNVCzs7kQxaUnTMMuDXkR8Wt12CMcVhQOGygmESBIIQP1NqcRuAvyqW1us9+wi xEcNDy8EY2Ddn6lOPLt2EJFVwgqRaclBW5r3UUPGe09erNylWv5yM1AXplI9Dqz5W++0 u4GQ== X-Gm-Message-State: AOAM530GVxliSFDl1KiNMlv4LTUjY8EbVl51REGLmED4T4WZDSdALUg0 Asq0RULo+1EC7+cBbDrIO+1VVa95 X-Google-Smtp-Source: ABdhPJwzt+qYtQk4Itq6BjkRL4I9l9MDQodqj52i7Q+5ll5p2zaqySUb/1t2bjQhDL+ex6NKXyx1Ng== X-Received: by 2002:a63:2c4:: with SMTP id 187mr14322737pgc.367.1593509410675; Tue, 30 Jun 2020 02:30:10 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id n14sm2108109pgd.78.2020.06.30.02.30.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 02:30:10 -0700 (PDT) To: "sipcore@ietf.org" From: OKUMURA Shinji Message-ID: Date: Tue, 30 Jun 2020 18:30:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] RFC4028 : bug in 11 Security Considerations (once again) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:30:12 -0000 Since the subject and the discussion have diverged, I will sort out the topic once again. The issue I raised: 11. Security Considerations Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response and force the UAC to continue to generate rapid requests. If the rogue UAS returns again a 2xx with a very small session interval, the attack will continue. My suggestion: The UAC compares the SE-value in 2xx response with the maximum value of the Min-SE. If the SE-value is less than the maximum MSE-value, then the UAC should consider the SE-value as the maximum MSE-value. Other suggestion: The UAC should immediately terminate a call. How is it? Regards, Shinji From nobody Tue Jun 30 06:51:40 2020 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 5BBCD3A0879 for ; Tue, 30 Jun 2020 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFJntYhroDuQ for ; Tue, 30 Jun 2020 06:51:37 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 69B5F3A0878 for ; Tue, 30 Jun 2020 06:51:37 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id s14so8497543plq.6 for ; Tue, 30 Jun 2020 06:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JL/1GqOXYgfGyg1h1rAeDP/HabmdhHRZuIQz0fBmC5U=; b=Mxb1p/vvda+kUk9xnYTykniV5Hw2hMs8QhDwrgV/8U/xYk6RoHa8yacSMrQ2jOUGeK 7S5oQRxtUxV+Z9DZ7jHVbZMDKnRxMEz29aEz7FN/ybSdh9yM+EZQk29r4gT97JbPDZoO w3ViAFwrCpRSbnrlSKaTOC4RgbLjQZ2zSZ6Ij9ctBOV0Mv7NYF4RWpgyMn2VpcwDxsOV WHo0LXFNvM6bnaW3N2RnXzh9PQSc7Jf3vDo1L2wMJAiHBPTFqE36crUsy+ZQrw6LS4Ek FYdfDFc+rrT51mOQg4TbfAEiIAthRKZpAZoi/dlA1zTHK3lBl653lYFU7yMRC+dgYSqN 2EFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JL/1GqOXYgfGyg1h1rAeDP/HabmdhHRZuIQz0fBmC5U=; b=d7KKb4WPJXeLxA53wCggRywD4rYcJQcrMeBgR8l0fhPvmNJj0zns/MWm/0HFX+C0mK Ng85DWKwcZ9rF+Us+esg2fgHHY8VzORJFuZgSp+ujjrJoNwsI8N8N9aVSQjMGQAF2C/J 92ODylj3lI3ZphI7OJkCWXpYM+T1KtTVRbKPVUUYA2GtOe9eAgylDSnoz7qCUoIv0Cmd 0N5O3ZOyuFwjBxOQ8xnXY2THk+r67394Bi8qGgeGo3gLPDVw/ktDe80nYkjfqiTqcalP Cd7mGbP4NX1cWDKdvngZvgcJ6YU8WL7m1eABsFN6VZKUaPADcUkIjuE8nERChJjFPskJ T1Lw== X-Gm-Message-State: AOAM533wdh0Ui4408ut7B0y6n7Bqsq9wgRyqm6f+BixfGwB+92GYJauh F27/OhUyI5gDUl2Ry/ZvSlulBkTp X-Google-Smtp-Source: ABdhPJwe6nOQeyY3G5RfKwmCgeEpuI5WBTd2x1kHFrFTEeQIhgiJgoJnvMcToqhb96wY2O3x3coCxw== X-Received: by 2002:a17:90a:e017:: with SMTP id u23mr7708321pjy.179.1593525096294; Tue, 30 Jun 2020 06:51:36 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.2.er.eaccess.ne.jp. [112.136.68.2]) by smtp.gmail.com with ESMTPSA id g140sm2814099pfb.48.2020.06.30.06.51.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 06:51:35 -0700 (PDT) From: OKUMURA Shinji To: Paul Kyzivat , SIPCORE References: <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <70fac3da-41d4-8bef-3c7f-617d8a3175ce@gmail.com> <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> <027a72cf-9fcb-20cc-2bfa-0821123c5522@gmail.com> Message-ID: Date: Tue, 30 Jun 2020 22:51:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <027a72cf-9fcb-20cc-2bfa-0821123c5522@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200630-0, 2020/06/30), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 13:51:39 -0000 Sorry. My diagrams were drawn assuming the UPDATE request contains an SDP offer. On 2020/06/30 13:32, OKUMURA Shinji wrote: > Hi Paul, > > My diagrams were drawn assuming there is no SDP in the UPDATE request. > One of the issues is when the ST negotiation(initiated by INVITE) period ends. 20xx, 4xx or ACK? > >> I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both. > > I agree with you. But O/A rules are written based on offer and answer, not transactions, so it's not easy to make a unified set. And this rule is likely to be further complicated by the fact that the ST cannot handle 18x responses. > > Regards, > Shinji > > On 2020/06/30 4:53, Paul Kyzivat wrote: >> Shinji, >> >> IIUC you are suggesting to use the same rules for ST as for O/A. >> >> I don't think your diagrams are sufficient to describe the rules. They only talk about the types of messages, not the content of the messages. >> >> I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both. >> >> For one thing, in all of the messages that are being used for O/A it is actually the case that ST is being negotiated, even if only in the negative. >> >> An interesting odd case is if an INVITE is used to initiate an O/A, and then an UPDATE is used within it to negotiate ST but not carrying any SDP. >> >> Perhaps we should simply declare it is glare if there are overlapping INVITE or UPDATE in opposite directions regardless of what they contain. That would certainly simplify things. >> >>      Thanks, >>      Paul >> >> On 6/29/20 9:14 AM, OKUMURA Shinji wrote: >>> According to current regulations, UAs treat UPDATE with SDP as follows: >>> >>>                        A                      B >>>                        |                      | >>>                        |INVITE(offer)         | >>>                     +->|--------------------->|<-+ >>> Don't send INVITE  |  |                      |  | Don't send INVITE >>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>> 491 to INVITE      |  |                      |  | 500 to INVITE >>> 491 to UPDATE      |  |           2xx(answer)|  | 500 to UPDATE >>>                     +->|<---------------------|<-+ >>> may send INVITE    |  |                      |  | may send INVITE >>> may send UPDATE    |  |                      |  | may send UPDATE >>> may accept INVITE  |  |                      |  | may accept INVITE >>> may accept UPDATE  |  |ACK                   |  | may accept UPDATE >>>                     |  |--------------------->|  | >>>                     v  |                      |  v >>> >>> >>>                        A                      B >>>                        |                      | >>>                        |INVITE                | >>>                     +->|--------------------->|<-+ >>> Don't send INVITE  |  |                      |  | Don't send INVITE >>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>> 491 to INVITE      |  |                      |  | 500 to INVITE >>> 491 to UPDATE      |  |                   4xx|  | 500 to UPDATE >>>                     +->|<---------------------+<-+ >>>                        |                      |  | Don't send INVITE >>>                        |                      |  | may send UPDATE >>>                        |                      |  | may accept INVITE >>>                        |ACK                   |  | may accept UPDATE >>>                     +->|--------->    ------->|<-+ >>>                     v  |                      |  v >>>                        |                      | >>>         (4xx and ACK to it are atomic.) >>> >>> Regards, >>> Shinji >>> >>> On 2020/06/29 20:53, OKUMURA Shinji wrote: >>>> Hi Paul, >>>> >>>>> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. >>>> >>>> I understand your suggestion. Probably my suggestion might be a bit more complicated than the 491 response. >>>> However, the 491 response may not be so simple. I think we need to differentiate from the 500 response. >>>> >>>>                        A                      B >>>>                        |                      | >>>>                        |INVITE                | >>>>                     +->|--------------------->|<-+ >>>> Don't send INVITE  |  |                      |  | Don't send INVITE >>>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>>> 491 to INVITE      |  |                      |  | 500 to INVITE >>>> 491 to UPDATE      |  |            2xx(offer)|  | 500 to UPDATE >>>>                     +->|<---------------------|<-+ >>>> Don't send INVITE  |  |                      |  | Don't send INVITE >>>> Don't send UPDATE  |  |                      |  | Don't send UPDATE >>>> 491 to INVITE      |  |                      |  | 500 to INVITE >>>> 491 to UPDATE      |  |ACK(answer)           |  | 500 to UPDATE >>>>                     +->|--------------------->|<-+ >>>>                     v  |                      |  v >>>> >>>> Regards, >>>> Shinji >>>> >>>> On 2020/06/28 0:45, Paul Kyzivat wrote: >>>>> On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >>>>>> Hi Paul, >>>>>> >>>>>> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. >>>>> >>>>> If we want to follow the precedent of O/A glare, then I think it is MUST reject. >>>>> >>>>>> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? >>>>> >>>>> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. >>>>> >>>>>      Thanks, >>>>>      Paul >>>>> >>>>>> Regards, >>>>>> Shinji >>>>>> >>>>>> On 2020/06/26 4:24, Paul Kyzivat wrote: >>>>>>> Roman, >>>>>>> >>>>>>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>>>>>> Hi Paul, >>>>>>>> >>>>>>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >>>>>>>> >>>>>>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >>>>>>>> >>>>>>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. >>>>>>> >>>>>>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. >>>>>>> >>>>>>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. >>>>>>> >>>>>>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. >>>>>>> >>>>>>>      Thanks, >>>>>>>      Paul >>>>>>> >>>>>>>> Best Regards, >>>>>>>> _____________ >>>>>>>> Roman Shpount >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >>>>>>>> >>>>>>>>     ISTM that the key issue Shinji is raising is that it could be >>>>>>>>     problematic to raise an error to an UPDATE that is doing a target >>>>>>>>     refresh. This is true regardless of what else the UPDATE is doing - an >>>>>>>>     offer, session timer refresh, or maybe nothing else. >>>>>>>> >>>>>>>>     The bottom line here is that if you have an urgent need to do a target >>>>>>>>     refresh, you should do it with a request that has little to no >>>>>>>>     chance of >>>>>>>>     being rejected. >>>>>>>> >>>>>>>>     This is of course under the control of the UAC. If the UAC chooses >>>>>>>>     to do >>>>>>>>     a target refresh with an UPDATE, and in conjunction with a session time >>>>>>>>     refresh (and/or offer) then it should be prepared for the consequences >>>>>>>>     if the UPDATE is rejected (with 491 or anything else.) >>>>>>>> >>>>>>>>     I guess we could discuss how much (if any) of this logic ought to be >>>>>>>>     included in the document. >>>>>>>> >>>>>>>>     I don't think this alters the validity of using 491 for a session timer >>>>>>>>     glare situation. >>>>>>>> >>>>>>>>              Thanks, >>>>>>>>              Paul >>>>>>>> >>>>>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>>>>>     >>>>>>>>      > >> wrote: >>>>>>>>      > >>>>>>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>>>>>      >      >> I'm not going to deny the solution with the 491 response, >>>>>>>>     but I >>>>>>>>      >     think it has a big impact. >>>>>>>>      >      > >>>>>>>>      >      > The situation with session timers is different from target >>>>>>>>      >     refresh. Target refresh is updated for each UA independently. >>>>>>>>      >     Session timer is negotiated for the entire session, so more >>>>>>>>      >     collision scenarios are possible. One of such scenarios is >>>>>>>>     both UA >>>>>>>>      >     sending UPDATE at the same time. If these UPDATE requests do not >>>>>>>>      >     carry SDP, currently they should be accepted. Resulting session >>>>>>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>>>>>     ambiguous >>>>>>>>      >     session timer state in this case is to refuse the UPDATE message, >>>>>>>>      >     similar to the session description collision. This is why 491 was >>>>>>>>      >     suggested. >>>>>>>>      > >>>>>>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>>>>>      > >>>>>>>>      > >>>>>>>>      > It was discussed but nothing is final. >>>>>>>>      > >>>>>>>>      >     If so, the UPDATE for target-refresh and the one for >>>>>>>>     session-refresh >>>>>>>>      >     are combined, as such they affect each other. And I think the >>>>>>>>     result >>>>>>>>      >     will be rarely ambiguous, if there is no change in the >>>>>>>>     session timer >>>>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>>>>>>>      >     reject the UPDATE request? If the UPDATE with new >>>>>>>>     remote-target-uri >>>>>>>>      >     is rejected, the UA will be unreachable. >>>>>>>>      > >>>>>>>>      > >>>>>>>>      >   This should be no different than the UPDATE with SDP collision. >>>>>>>>     I am >>>>>>>>      > not sure what problem you are talking about. >>>>>>>>      > >>>>>>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>>>>>>>      >      > This is exactly the reason why handling of UPDATE transaction >>>>>>>>      >     collisions needs to be resolved. If session timer ends up in an >>>>>>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>>>>>     UA will >>>>>>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>>>>>     result in >>>>>>>>      >     a collision. >>>>>>>>      > >>>>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>>>>>     to avoid >>>>>>>>      >     collisions on retransmission. And we also need to decide how UAs >>>>>>>>      >     detect collisions. >>>>>>>>      > >>>>>>>>      > >>>>>>>>      > I am not sure what you are talking about. >>>>>>>>      > _____________ >>>>>>>>      > Roman Shpount >>>>>>>> >>>>>>> >>>>> >> From nobody Tue Jun 30 10:22:35 2020 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 1B4863A07C6 for ; Tue, 30 Jun 2020 10:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9YUd1wiSH8UN for ; Tue, 30 Jun 2020 10:22:32 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 6B1023A07D2 for ; Tue, 30 Jun 2020 10:22:32 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id 76so4613993otu.9 for ; Tue, 30 Jun 2020 10:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wln3cm7Ek9kxCkZSrBgHupzGXxUXJiAFmiEoTbbs44E=; b=rx7qEi2I+8R8mO70nx09qBPeeuXVoWLSp3jR9anR08rFE/EkxmesiaXokeFRb5klf7 h3dSZ756Q6MBPGV+dYRRlOtfBhP1rctcQXYAhGBPxz/Prvr8U0WmmllgeZSk+4AgOJ1y QHSrmHkaJOnrN5IJZnJyxKNNmgOXj2CJhAvn70g5iAOC2qWxu3cpDGIl6m82A/uhNbtY sF/9Lcw6UclQxfUz+UcQVBaTM8taXU5EHaZOXjMXThQ2W1q0zw92Mljlq0aa1NUUFDWE y9RqOiXYPdRBrNjocLRWqkL8j00P9hbsq39DodoSlIhowlxsXftsrqXwnOQhhMWs4m9G EGGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wln3cm7Ek9kxCkZSrBgHupzGXxUXJiAFmiEoTbbs44E=; b=abEzraOjq8mYEHh1wk/zypJUQHw4Op8GNA0DmjeO96PKbk9UaAMTQqOn2/ugjV1PIb 4GCpftKwlHwGoFoT8wYyJZw/3Q7IPuOi6h/8GDBcIys23p/7cF8RjV9fAnjbTpnHiNwj GC3YeCme8bDERtu5QINlPACXtSh+mUGp3xWPaAqmaWMmN0lf7N01XNYcnbEsa6wTkqqE Vjxar+SKverhoQqivIAkECwlnhGactUThxWY4Asyy4E/z2WsvOHaj6AGqjUPzqtYSJVg Rib9Z5iv7RAvOAkoEx0DKJSmxBTz/YTYi9IU5zizHGQt+eVhep6OFmYWf8f7EOe6VUZZ +xWw== X-Gm-Message-State: AOAM530z0zlqsHDPgnGg7tJmWMAui25zhS/K9dpLlF01N2NxqkgxM+E5 cpq5Abt4RHUs3SQ+juKKR3xr++f4TFM= X-Google-Smtp-Source: ABdhPJxaKD5ZG3RjYyE7w1hK+FrHkTO3iHBOz5BM7mpkHCLHS/6B+a/fV60WaGCF4SGe9NWIm7YSHg== X-Received: by 2002:a05:6830:14c6:: with SMTP id t6mr5951742otq.18.1593537750993; Tue, 30 Jun 2020 10:22:30 -0700 (PDT) Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com. [209.85.161.45]) by smtp.gmail.com with ESMTPSA id 123sm851263oop.14.2020.06.30.10.22.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 10:22:30 -0700 (PDT) Received: by mail-oo1-f45.google.com with SMTP id s190so718417ooa.13 for ; Tue, 30 Jun 2020 10:22:29 -0700 (PDT) X-Received: by 2002:a4a:83d5:: with SMTP id r21mr8698368oog.19.1593537749563; Tue, 30 Jun 2020 10:22:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 30 Jun 2020 13:22:18 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007fbdd805a9506b7a" Archived-At: Subject: Re: [sipcore] RFC4028 : bug in 11 Security Considerations (once again) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:22:34 -0000 --0000000000007fbdd805a9506b7a Content-Type: text/plain; charset="UTF-8" How does UAC know the maximum value of the Min-SE? If we require UAS return Min-SE in 2XX and for proxies to verify that Min-SE is equal or higher then the value they have set, then it would be possible to enforce this rule. Otherwise, the value Min-SE set by the proxy and ignored by UAS would only be known to the proxy. _____________ Roman Shpount On Tue, Jun 30, 2020 at 5:30 AM OKUMURA Shinji wrote: > Since the subject and the discussion have diverged, I will sort out the > topic once again. > > The issue I raised: > > 11. Security Considerations > Next, consider the case of a rogue UAS that wishes to force a UAC to > generate refreshes at a rapid rate. In that case, the UAC has to > support session timer. The initial INVITE arrives at the rogue UAS, > which returns a 2xx with a very small session interval. The UAC uses > this timer and quickly sends a refresh. Section 7.4 requires that > the UAC copy the current session interval into the Session-Expires > header field in the request. This enables the proxies to see the > current value. The proxies will reject this request and provide a > Min-SE with a higher minimum, which the UAC will then use. Note, > that if the proxies did not reject the request, but rather proxied > the request with a Min-SE header field, an attack would still be > possible. The UAS could discard this header field in a 2xx response > and force the UAC to continue to generate rapid requests. > > If the rogue UAS returns again a 2xx with a very small session interval, > the attack will continue. > > My suggestion: > The UAC compares the SE-value in 2xx response with the maximum value of > the Min-SE. If the SE-value is less than the maximum MSE-value, then the > UAC should consider the SE-value as the maximum MSE-value. > > Other suggestion: > The UAC should immediately terminate a call. > > How is it? > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000007fbdd805a9506b7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How does UAC know the maximum value of the Min-SE?
If we require UAS return Min-SE in 2XX and for proxies to verif= y that Min-SE is equal or higher then the value they have set, then it woul= d be possible to enforce this rule. Otherwise, the value Min-SE set by the = proxy and ignored by UAS would only be known to the proxy.
_____________
Roman Shpount


On Tue, Jun 30= , 2020 at 5:30 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:
Since the subject and the discussion have diverged,= I will sort out the topic once again.

The issue I raised:

11.=C2=A0 Security Considerations
=C2=A0 =C2=A0 Next, consider the case of a rogue UAS that wishes to force a= UAC to
=C2=A0 =C2=A0 generate refreshes at a rapid rate.=C2=A0 In that case, the U= AC has to
=C2=A0 =C2=A0 support session timer.=C2=A0 The initial INVITE arrives at th= e rogue UAS,
=C2=A0 =C2=A0 which returns a 2xx with a very small session interval.=C2=A0= The UAC uses
=C2=A0 =C2=A0 this timer and quickly sends a refresh.=C2=A0 Section 7.4 req= uires that
=C2=A0 =C2=A0 the UAC copy the current session interval into the Session-Ex= pires
=C2=A0 =C2=A0 header field in the request.=C2=A0 This enables the proxies t= o see the
=C2=A0 =C2=A0 current value.=C2=A0 The proxies will reject this request and= provide a
=C2=A0 =C2=A0 Min-SE with a higher minimum, which the UAC will then use.=C2= =A0 Note,
=C2=A0 =C2=A0 that if the proxies did not reject the request, but rather pr= oxied
=C2=A0 =C2=A0 the request with a Min-SE header field, an attack would still= be
=C2=A0 =C2=A0 possible.=C2=A0 The UAS could discard this header field in a = 2xx response
=C2=A0 =C2=A0 and force the UAC to continue to generate rapid requests.

If the rogue UAS returns again a 2xx with a very small session interval, th= e attack will continue.

My suggestion:
The UAC compares the SE-value in 2xx response with the maximum value of the= Min-SE. If the SE-value is less than the maximum MSE-value, then the UAC s= hould consider the SE-value as the maximum MSE-value.

Other suggestion:
The UAC should immediately terminate a call.

How is it?

Regards,
Shinji

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--0000000000007fbdd805a9506b7a-- From nobody Tue Jun 30 17:49:53 2020 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 5F3843A083E for ; Tue, 30 Jun 2020 17:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI7KueWcFAm9 for ; Tue, 30 Jun 2020 17:49:49 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 39EDD3A083C for ; Tue, 30 Jun 2020 17:49:49 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id f2so9195443plr.8 for ; Tue, 30 Jun 2020 17:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V6sqlOV59EgaRN3uNzPkGc4ABDC/x3Haj7l5umJ8xiY=; b=TzmFvO8KvN9vZQMru8iL6zFm7RTggr2y7NsvuGMDRTdRj1FcDKQkuIJdHjPk7PnsgU t7rx4V8VDjn0LoCz1JrspBvWj6wQjHAq4flVTllXX46potqAG/9M7I2FPTchc4kutDVz KFEnEYO541NcNqr6QCQLQKtyyK3jVAsAFP+7LUgh8tmZFukeYOxvw283mLGkY+4WNmW9 FVsl9Z4Oc9qzgyRoRaFLJ+cS2ETOoPUWB4WHhw3CvH5by1yQaOpDa/j8jGAZMjZJLf8a P8uU0WQZTdw9ZCrFB5q+Xh80IHDRFqmGp+twmKS4evNAEebB1kj/9dRS3HB0QHMZAu1m qoJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V6sqlOV59EgaRN3uNzPkGc4ABDC/x3Haj7l5umJ8xiY=; b=WkDlWy5aY4Wa4q9je6Tl+xP2wWsyXEz2T8GJoFLQFI8dajaMJq8/f4AfXb0ZtM7wjz m4U40V7Uf6L0HTgDHbDZkEx61ILojSHhjCFZLzScP2MuSnGmsWe9JgYAhfzIk/Ys3NRp Ojb6C5+Nk7JDiO990gd7vdswvKEyWdkJCYyPFJNqlmKqvXIoEFj8GiwqTDXW3V6N3dib s3/QLI+lINjBsA523ZfcniJK3+djlc9XF+BpX5iHuCQ1Yq/r46+h2WnXJ4XQJvYjGkdm BStW1okCiAYBSH9dIOOV/mgUfmLz8L67X8FaQ03/IsoHlGeN8fCGDVOK4NX0S16n6WVC ch8Q== X-Gm-Message-State: AOAM531EJLiHJKcnhhD8+3KNrRRIOGgPpKj88D7GShwclItGrQrNmYfe RbuARlifLnY7wjDNFJPsbktNHfsg X-Google-Smtp-Source: ABdhPJwipgzq+mlHOxCsJW0YSuBfiHuVN2+loIYlJMzOczlh3D23OKHvuvPc6aFaU0Wg7GhgubDYsg== X-Received: by 2002:a17:90b:f92:: with SMTP id ft18mr24682965pjb.1.1593564588183; Tue, 30 Jun 2020 17:49:48 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 200sm3753340pfy.57.2020.06.30.17.49.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 17:49:47 -0700 (PDT) To: Paul Kyzivat , sipcore@ietf.org References: <7fbe33de-78ad-8f07-5c27-caaab2ba933c@alum.mit.edu> <1e585edc-283a-6f0d-08f5-995d01163a3d@gmail.com> <8ffddcca-e755-07b7-098c-d4acae8222c3@alum.mit.edu> <4a3ac9c4-3de2-a2f2-afb1-37235ca31c90@alum.mit.edu> <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> From: OKUMURA Shinji Message-ID: <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> Date: Wed, 1 Jul 2020 09:49:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [sipcore] option tag (was RFC4028 : bug in 11 Security Considerations) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:49:52 -0000 Paul, > I think this probably suggests that an option tag for support of the updated ST draft would be helpful. Defining a new header that limits the double-meaning of a transaction may be useful for other issues. Regards, Shinji On 2020/06/28 3:38, Paul Kyzivat wrote: > Some further thoughts on this... > > On 6/27/20 11:45 AM, Paul Kyzivat wrote: >> On 6/27/20 7:02 AM, OKUMURA Shinji wrote: >>> Hi Paul, >>> >>> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response. >> >> If we want to follow the precedent of O/A glare, then I think it is MUST reject. >> >>> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right? >> >> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec. > > I subsequently realized that if we specify the use of 491 for ST then we must consider what happens in cases of interop with an older implementation that doesn't do that. > > If we have one UA supporting the extension and one that doesn't we first will have to decide whether to use an option tag so the two can know who does and doesn't support them. If so, then the 491 would not be used by either end in ST glare cases, and everything would work as currently. > > If no option tag is used, then the UA that supports it may send a 491 to indicate glare, but the other end won't, and also won't know precisely what to do when receiving one. We will then have to figure out what the end that does support the extension can do to fix things as best it can. > > In that case, it may be ok to allow the use of 491 to be optional, with the alternative being to proceed as if the other end doesn't support the extension. > > I think this probably suggests that an option tag for support of the updated ST draft would be helpful. > >>      Thanks, >>      Paul >> >>> Regards, >>> Shinji >>> >>> On 2020/06/26 4:24, Paul Kyzivat wrote: >>>> Roman, >>>> >>>> On 6/25/20 2:20 PM, Roman Shpount wrote: >>>>> Hi Paul, >>>>> >>>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers. >>>>> >>>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later. >>>>> >>>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document. >>>> >>>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare. >>>> >>>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate. >>>> >>>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail. >>>> >>>>      Thanks, >>>>      Paul >>>> >>>>> Best Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat > wrote: >>>>> >>>>>     ISTM that the key issue Shinji is raising is that it could be >>>>>     problematic to raise an error to an UPDATE that is doing a target >>>>>     refresh. This is true regardless of what else the UPDATE is doing - an >>>>>     offer, session timer refresh, or maybe nothing else. >>>>> >>>>>     The bottom line here is that if you have an urgent need to do a target >>>>>     refresh, you should do it with a request that has little to no >>>>>     chance of >>>>>     being rejected. >>>>> >>>>>     This is of course under the control of the UAC. If the UAC chooses >>>>>     to do >>>>>     a target refresh with an UPDATE, and in conjunction with a session time >>>>>     refresh (and/or offer) then it should be prepared for the consequences >>>>>     if the UPDATE is rejected (with 491 or anything else.) >>>>> >>>>>     I guess we could discuss how much (if any) of this logic ought to be >>>>>     included in the document. >>>>> >>>>>     I don't think this alters the validity of using 491 for a session timer >>>>>     glare situation. >>>>> >>>>>              Thanks, >>>>>              Paul >>>>> >>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote: >>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji >>>>>     >>>>>      > >> wrote: >>>>>      > >>>>>      >      >> 1. Handling of UPDATE with no SDP glare >>>>>      >      >> I'm not going to deny the solution with the 491 response, >>>>>     but I >>>>>      >     think it has a big impact. >>>>>      >      > >>>>>      >      > The situation with session timers is different from target >>>>>      >     refresh. Target refresh is updated for each UA independently. >>>>>      >     Session timer is negotiated for the entire session, so more >>>>>      >     collision scenarios are possible. One of such scenarios is >>>>>     both UA >>>>>      >     sending UPDATE at the same time. If these UPDATE requests do not >>>>>      >     carry SDP, currently they should be accepted. Resulting session >>>>>      >     timer state is ambiguous. The only reliable way to prevent >>>>>     ambiguous >>>>>      >     session timer state in this case is to refuse the UPDATE message, >>>>>      >     similar to the session description collision. This is why 491 was >>>>>      >     suggested. >>>>>      > >>>>>      >     First of all, is a 491 rejected solution planned for bis? >>>>>      > >>>>>      > >>>>>      > It was discussed but nothing is final. >>>>>      > >>>>>      >     If so, the UPDATE for target-refresh and the one for >>>>>     session-refresh >>>>>      >     are combined, as such they affect each other. And I think the >>>>>     result >>>>>      >     will be rarely ambiguous, if there is no change in the >>>>>     session timer >>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs >>>>>      >     reject the UPDATE request? If the UPDATE with new >>>>>     remote-target-uri >>>>>      >     is rejected, the UA will be unreachable. >>>>>      > >>>>>      > >>>>>      >   This should be no different than the UPDATE with SDP collision. >>>>>     I am >>>>>      > not sure what problem you are talking about. >>>>>      > >>>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE >>>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm. >>>>>      >      > This is exactly the reason why handling of UPDATE transaction >>>>>      >     collisions needs to be resolved. If session timer ends up in an >>>>>      >     ambiguous state, it is likely ambiguous for both UA and both >>>>>     UA will >>>>>      >     initiate an UPDATE refresh request to confirm, which will >>>>>     result in >>>>>      >     a collision. >>>>>      > >>>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure >>>>>     to avoid >>>>>      >     collisions on retransmission. And we also need to decide how UAs >>>>>      >     detect collisions. >>>>>      > >>>>>      > >>>>>      > I am not sure what you are talking about. >>>>>      > _____________ >>>>>      > Roman Shpount >>>>> >>>> >> >> _______________________________________________ >> 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