From nobody Wed Jul 1 01:40: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 0A6953A0B3C for ; Wed, 1 Jul 2020 01:40: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 PDn0rYa9u-6J for ; Wed, 1 Jul 2020 01:40:25 -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 8E31E3A0B72 for ; Wed, 1 Jul 2020 01:40:25 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id u9so6026539pls.13 for ; Wed, 01 Jul 2020 01:40:25 -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=zNoEnL8JJHfQ8cCaoHmoDwv4DiBUIcMKhcKBHlLuXOs=; b=Yws3AvjrrRLc/rbLxo8P7Bdw3oiQvHvt1WktqbFyKP7ZOXsqGwMVjmAyYY1vsXyR5P gg63G6qY8LubyWG663Uv3MJd+mSUAAy1X5Z6NW1FpyrhfY9CxZsaxnkmR4HqWfhoYpni MFqIZbZg6FSMPgGArFrWBkQv8fhFsNOJvtBJrrU2xtcI7CVNzm8Et7MSiXOZaMXbtFm+ 8r363q0YWT+ecypw9bglO/WsobbwftiLTACqN139VZO9indkUiRwYnZ6z5WMIlXyybsa on5HePqBNV1vGClPJRGLwhx9BxxjNz8YyAPK/EPHeH6W/dQV3CrkrSyKCgNjkKV1e4cR qZQQ== 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=zNoEnL8JJHfQ8cCaoHmoDwv4DiBUIcMKhcKBHlLuXOs=; b=bi6K3j2PoZptOpZTuPQk+xtTWZzpvIuFWIy6IISl3AAmxFIMMOh7kgkfhNWNFktw+S vmof22lFXq9S3lQS1xqKHCwo6t60vpWrune0kSOhs8YTA9J2DkTSx8mcxpdZCIFVEJ+P OMneWfpzr8al4HvJWodkvid/PYYnkzwzEqel/h0Jgquzk12ejLVhNQRuPg0Q8Tn7146j kQSviBNwcUxCEz9zJVLi5iPpJZ14LHZyQGRVbfUKI3zWm/zgio5jP9n+kDjzzboxgIz+ /GZwTKTYC1eT6Q726yPOJn5rAaFLVF6tc5YWy8h4ypa04YbjaTgBobXx+qhhM/MsfGX8 LPSw== X-Gm-Message-State: AOAM533AdwPtk/l6czMUlnAX3NALRuksQJwI3zX4+RVtef/2PmpZeXJU qX7HeFgnfnfJH9uyJ7CmRFRtlkrQ X-Google-Smtp-Source: ABdhPJzfwknv+/d2MQxpUXtgcNzY1+E/k4lMAfVgTnDvX1SlE8ZqMsjJwZ9xh8Hnp0/aM18OGfRGFQ== X-Received: by 2002:a17:90b:19cc:: with SMTP id nm12mr19175770pjb.144.1593592824854; Wed, 01 Jul 2020 01:40: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 c12sm5183819pfn.162.2020.07.01.01.40.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2020 01:40:24 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount References: From: OKUMURA Shinji Message-ID: <3688f589-d467-2144-0fae-6229266af109@gmail.com> Date: Wed, 1 Jul 2020 17:40: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 : 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: Wed, 01 Jul 2020 08:40:27 -0000 Roman, I first suggested how the UAC would use the maximum value of MSE. How the UA knows the maximum MSE is the next topic. At least a caller UA knows its own MSE. And the UA may receive a session refresh request, even if it is refresher. However it is a passive event, it doesn't happen for sure. Q. How does a UA know the correct maximum value of the Min-SE? A1. When a dialog is established, both UAs send a session refresh request with its own Min-SE. However, regulations are needed to prevent them from sending at the same time. A2. When a dialog is established, either UA sends a session refresh request with its own Min-SE. And the UAS return Min-SE in 2xx. In either case, UA may receive 422 responses, but only once. Regards, Shinji On 2020/07/01 2:22, Roman Shpount wrote: > 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 > From nobody Wed Jul 1 08:54: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 B34723A11AB for ; Wed, 1 Jul 2020 08:54:40 -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 8wRmWiskSNRf for ; Wed, 1 Jul 2020 08:54:38 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2053.outbound.protection.outlook.com [40.107.237.53]) (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 C18FD3A1134 for ; Wed, 1 Jul 2020 08:54:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mqQfXxULjwpNf+MoEstnMjZ3NdcN2vZsuZ1m4xxxWNsCmd6bBCEQoIu25qPSrJ/QfbwNeDfB36fTEZJp557v4Fvm+0Ngpuy7CO/fsfTQysDdgpJT52+HvpoBSgUmtomRK57U2s4Ve+9M/ci50ttdhA+4iWEzdl2HpPDq2HCBYvB2M7K1LzZK1iKRe/PNhLpxN4akSclSn19tKbXmHhBrt5TgivGCbXRpa4VJRvn7o8stRqexJnYQS0Ja2clK0jCROnq583AVQSSvCIECcXj9Y+AyeG0Ns3UbZJOdESV9B6DmZx4yGDFa6OK+bIMsxgnssyh0CAmyAbDLWwr3J93D3A== 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=ni38p+EtK6IuVd89E/2rm3oHx9aWpSFJHiH/AVcO4kU=; b=asKuiiFwAKm/e0SnTEziudU1W6vYyz25qzziqD0Ed+pNdUYH8fcSPeTQtTWYpZwyoCdOvEyGvb+ZLBy+XxUqtMDSy15ecDDg1XUbbS8nu1ZX/aQa7WPjUFUIG3p4pzQnc9Qql1A03bUi70SID1NV33PDqKwmoGTFpuCeSd67QGbARHvNoMhxlqRf5dsfoEhYRdp8MEZgGz8BvP3JWPoqGU6WQKEIq4SxxGof5SG/1ZhPIZvz1YJ/NPyh31KFkZgR7ZWL0irYYDTCGp+kqAIwc7OQDWxTuIx6XR810shZk+sWtLZhQX8duwtWL3km+x/3/V/5HFG9wKOm25OaWkyiUQ== 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=ni38p+EtK6IuVd89E/2rm3oHx9aWpSFJHiH/AVcO4kU=; b=V53l0FoHW0NBkA/kiC+F4BZn9qwJ+i1qeb4YSF2Rntg6Wt2+DrSpr3dZGLN7SWZNiCpZK+EycYlN9vUlfGRXlwrTtuY/JVjCfXfRWmCWdWh/xyNJc3Jsx8ik7EGFh/UcPB7tt4lDI7mLDFAQywjcUr6SWC8Toigicv0+QsQttco= Received: from DM5PR18CA0069.namprd18.prod.outlook.com (2603:10b6:3:22::31) by MWHPR1201MB0063.namprd12.prod.outlook.com (2603:10b6:301:4d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Wed, 1 Jul 2020 15:54:31 +0000 Received: from CY1NAM02FT040.eop-nam02.prod.protection.outlook.com (2603:10b6:3:22::4) by DM5PR18CA0069.outlook.office365.com (2603:10b6:3:22::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23 via Frontend Transport; Wed, 1 Jul 2020 15:54:31 +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 CY1NAM02FT040.mail.protection.outlook.com (10.152.75.135) 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, 1 Jul 2020 15:54:30 +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 061FsRwY000997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Jul 2020 11:54:28 -0400 To: OKUMURA Shinji , sipcore@ietf.org References: <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> <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> From: Paul Kyzivat Message-ID: <9571d4c4-8478-98db-43cc-93dce969f142@alum.mit.edu> Date: Wed, 1 Jul 2020 11:54:27 -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: <828031fd-1699-bac3-7f0d-7b8acf532b64@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:(376002)(346002)(39860400002)(396003)(136003)(46966005)(47076004)(36906005)(75432002)(70586007)(8936002)(7596003)(336012)(316002)(15650500001)(86362001)(2906002)(356005)(70206006)(82310400002)(31686004)(82740400003)(26005)(31696002)(966005)(2616005)(786003)(53546011)(186003)(956004)(5660300002)(83380400001)(478600001)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 566d5fc5-100d-4a35-0b5f-08d81dd70a87 X-MS-TrafficTypeDiagnostic: MWHPR1201MB0063: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mjW3LYmGd1ykAR3Wb4fnZDXpINMiLtz29U/Wx3YhQ3Wtd1WisBc8z2RZJvBJOaKOPdQsQqX8K8WlWSqOxLdrLGB6V3ePG58LWqNuYZ1rwOLG0Gdm3zh8S2Vej/jUU6achBHmk+WOorzOsL6RONHSVA0mZfc2M/5wDF9wutC6eOlAOZbx6cA1T1ST2AJRr9bnIxMbRnKSJxf86XKUUZqBb8dtfsyHDINaUajuq5m7/m0Q8bCS15U1l2d253UtBof37ag07k6LpojGVLdWOvE5tDjvqjJhqsz9dTquAD6nHyRi4dA7mxc8h6PJlzE4GrNQtg13X40nPUiaIqyDAF8nDhJT43j0MFow1KeD8Ql8fZydcnCDOzZAMbnb+UHxyBxWdJSZzmGW5GnRmtTNhAXZvAB1AVAR/s9we7/nm0WgIT4VUXkXGRF6NzERCga4Tu/qtMOupx8pTkpmEzjTYRZ395cByySivmBzL7SVdt+qu/A0NVbK7q35t0+z0ht8njsJ X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 15:54:30.2432 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 566d5fc5-100d-4a35-0b5f-08d81dd70a87 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: CY1NAM02FT040.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0063 Archived-At: Subject: Re: [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 15:54:41 -0000 On 6/30/20 8:49 PM, OKUMURA Shinji wrote: > 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. Can you say more of what you are thinking? I was only suggesting an option tag that indicates support for the revisions in this bis. That gives a little more flexibility in how things work. It sounds like you something more specific in mind. Thanks, Paul > 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 From nobody Wed Jul 1 09:04: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 85BC13A1199 for ; Wed, 1 Jul 2020 09:04:18 -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 GivGcpy7nlZt for ; Wed, 1 Jul 2020 09:04:16 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2080.outbound.protection.outlook.com [40.107.223.80]) (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 CB0E83A1194 for ; Wed, 1 Jul 2020 09:04:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TaZH/RGhcXLznZK7+Fz1fxrDOwW5QwFjEfj85DncYsEglji2t+WPRfbwegSmPAcWIN+Uxmr4IhddAo6tvxwkxeAV5CX6oVEWQcCbbET/QsNjsSXsu2ZZr3FcDp3Jc+VPLMi11uBqI8XZoosSmqLg8NuFss61YyLtOGueM3ODAtcRa3+FSqfakqATRjNU+yzyYwMrVd6KUvRe/qgZxYg8h3VvRDx4XOllkMdECAjkUTu4+Csd4cdihcrIZ95eDEm5JAUrIA0czyJ/MFG8yprIcwxvhSQ/Tmrg3/XX8bRY0aEz69waOcsAqbjLvBkfCEAwg3G+E7EFeicH2fsvpPf4mw== 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=ADvUyhzzcB+ljY8X0nHsZN4PD3CLwm/UOF1Z+ysyVg4=; b=guYcsZBpyMXt9n0+WVe94SJ2vJ0vUdrDesJ7J3AU4e0nnFXefUZHTx6rkbwZUVdJcf4TXEwGGNX/ZRq4Xlfq9xXj2X/OFeF4WJYvaCWYhtnGdSjzyB6zI8hMVwQj8eHIu3BMx3knsJ6lsinqIUOHdqbtkAWiYA4Dm4AczQDVZbuWyJBKAdUoNIa0O22TSkAUKZjJUjfTRrF1SmU/5HR7LIaQid/FIo8hciL0+szhLzWEZGbdQS57LNeVwwI+wPhZfP0YSVOihCWsutvyVL5VoN1ELBkw9OK2VdOWLmemoVQA9dgQFdf1Kt7LUP5gUQwB3T8+jfG5Muw8gCKmhEoxLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=telurix.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=ADvUyhzzcB+ljY8X0nHsZN4PD3CLwm/UOF1Z+ysyVg4=; b=Ut4ZUQ56b9Mq9Fv3krkJwUpLi4EMkvWpBrESEvu6d/x/PM8u+qlG3zuHSyMvVNjfYbepK0MmTy54tkgx7KUg6IUTn1CDbhO6P6rOVhZWFOhODF9+P5D1CP3hTq+LRhec9i/DYs5fxzhcwL9b3xIwjY6JssE/4AYtnxbTxo65BSk= Received: from SN4PR0501CA0125.namprd05.prod.outlook.com (2603:10b6:803:42::42) by CH2PR12MB3733.namprd12.prod.outlook.com (2603:10b6:610:15::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20; Wed, 1 Jul 2020 16:04:15 +0000 Received: from SN1NAM02FT034.eop-nam02.prod.protection.outlook.com (2603:10b6:803:42:cafe::18) by SN4PR0501CA0125.outlook.office365.com (2603:10b6:803:42::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.13 via Frontend Transport; Wed, 1 Jul 2020 16:04:15 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=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 SN1NAM02FT034.mail.protection.outlook.com (10.152.72.141) 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, 1 Jul 2020 16:04:15 +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 061G4BCY001764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Jul 2020 12:04:12 -0400 To: Roman Shpount Cc: 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> <9bb32c53-6d35-cdeb-31ea-90451c91986c@alum.mit.edu> From: Paul Kyzivat Message-ID: <68185389-ace5-75b6-7e21-cd0c05111057@alum.mit.edu> Date: Wed, 1 Jul 2020 12:04:11 -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)(136003)(39860400002)(346002)(396003)(46966005)(336012)(31686004)(54906003)(82740400003)(6916009)(2616005)(7596003)(47076004)(36906005)(316002)(956004)(786003)(478600001)(8936002)(70586007)(2906002)(53546011)(5660300002)(356005)(4326008)(26005)(4744005)(186003)(15650500001)(75432002)(8676002)(31696002)(83380400001)(70206006)(82310400002)(86362001)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 261d77d5-e599-40de-0324-08d81dd8672d X-MS-TrafficTypeDiagnostic: CH2PR12MB3733: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AQ8+meZ+fiLGmRaLwrqNSUah7imYFi57GZj2h31DoCJyy9o7SmofabJQ1t8jRaC7QiaqAWiIuGUmOMWTO70kRTJ9pAms8kjN4wBFNp8spf3NsOeLgGupZkV/WBYiMRT3CSanC/Yntk7/nFpGTbCY3ELaW//l8T4WhNYtraIhcdWwZ/ZWBtke2keNoXXGG34FYLv9/5DxzwM9WS1kVJBLHYuYO1SvJnVar0gEmwF3TxP42H9Ba2Wd4CmxvbxYOCvImbdLpdnG1SgUgtfPNqmO4zbQO5xjQQPKppLrsGjra5fiAc0oSyl4kaptZF4au4pcBYwX+invt20F2sbRydmZ7ibpmWPjWlGDAtydzJ78kyb9b1eHljSBbTcQVRvZHDyoB88Z95bayvxSuHgZSHIPnZ63BxWwsWTKRJxx6wbUBvE/uPbaqed0iQZbJyXsc7pE X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 16:04:15.0911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 261d77d5-e599-40de-0324-08d81dd8672d 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: SN1NAM02FT034.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3733 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, 01 Jul 2020 16:04:19 -0000 On 6/29/20 5:02 PM, Roman Shpount wrote: > 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. OK. It seemed like a good idea at the moment, but doesn't fly. Thanks, Paul From nobody Wed Jul 1 22:35: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 89E373A0CF9 for ; Wed, 1 Jul 2020 22:35: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 QsEro-IjQnUm for ; Wed, 1 Jul 2020 22:35:09 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 533883A0C5A for ; Wed, 1 Jul 2020 22:35:09 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id j1so12030624pfe.4 for ; Wed, 01 Jul 2020 22:35:09 -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=zR1D6XMtCmW0HluQtkHIP7X83jEy11kzZDiq+g/lHqo=; b=J0dkBgZvZiTvkz6llF6HdSuPgLBH+Q2FwDFyfg2PgOyUu1DPtML8B+MvKvL2fItwDk evTI+IFB3JBxX6xLtU5Yj1Tuu0fDIeMHXxUGxWVk2haaImT2ELjbMy4+n17MYKlMAz7U D+SV/MBkN0GorSKe0fWTSYUyC6MwcLswEPp1bVhAhnP9lUH2vTdvVLzOdy/yurT9K4A6 i36S5LIvEYRQCn9TUdoZb1OVGnR2YHEU396nbD5LgLr2qTgEuwi5VDOM0VI/qAUq853q VVB32lGR+Egf8N6r/a2OzJKGm8UHyPI3QDIwzQpjQHvg1RmtooL0fu1eSdmtGlu8r8mK Ugow== 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=zR1D6XMtCmW0HluQtkHIP7X83jEy11kzZDiq+g/lHqo=; b=qWhF9SUDK1tm7VyawgVcWISgEXLlwly3wrPyGJ8FezeVmFe2yLldBgi2O7iZu7+AME NSyZMFJbEsVCV2g675fDX8yVkCrJkhtEQjrX7PA+oMzYsIzENNfstUUInSxVq+9+1U49 S1mEMxEN7tctSE+KSwaMeEFq+QPUR98HOmEPfYeP0CxTJAVMCmd36iqbNlg6u8JIaslO yktLLmcc+dPzr8fDYjld7IjgXqyhrR1H34Nat5/TgooV3xv8GWwDDSEzbl7PIH/ODzUe NgO/hEeD0Li9MoFCweFysBxsjSYgfVsUugXxs+IRL2k3yuML2JrCIajflIU58Qbvly5G wuQw== X-Gm-Message-State: AOAM531tXzDOJLD0IenpKnzo+Nr8NLrehRuHBSLSJtLsgpvXZeqCeeZD 0i9FooTBdJxgc+ndUoAFhmIZxN+i X-Google-Smtp-Source: ABdhPJx5VUwtNOUuneJ4p8p73MqWIj3jwo0f0KF3Hq/8ReXxbav0ZL2H5GbBcbRInM/NLgt/b0jGdg== X-Received: by 2002:a62:19c9:: with SMTP id 192mr8920816pfz.138.1593668108400; Wed, 01 Jul 2020 22:35:08 -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 n14sm7426985pgd.78.2020.07.01.22.35.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2020 22:35:07 -0700 (PDT) To: Paul Kyzivat , sipcore@ietf.org References: <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> <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> <9571d4c4-8478-98db-43cc-93dce969f142@alum.mit.edu> From: OKUMURA Shinji Message-ID: Date: Thu, 2 Jul 2020 14:35: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 In-Reply-To: <9571d4c4-8478-98db-43cc-93dce969f142@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] 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: Thu, 02 Jul 2020 05:35:12 -0000 Hi, UPDATE and PRACK transactions perform SDP negotiation, session timer negotiation, etc., but also have the function of indicating the target URI and confirming the provisional response. A 200 OK is interpreted as a success response for all meanings, but we sometimes want to reject a part of them. I think that new header can specify the intended function in the request or the unintended function in the response. This is what I'm currently thinking about. Regards, Shinji On 2020/07/02 0:54, Paul Kyzivat wrote: > On 6/30/20 8:49 PM, OKUMURA Shinji wrote: >> 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. > > Can you say more of what you are thinking? > > I was only suggesting an option tag that indicates support for the revisions in this bis. That gives a little more flexibility in how things work. It sounds like you something more specific in mind. > >     Thanks, >     Paul > > >> 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 > From nobody Thu Jul 2 07:40: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 69AF53A08DC for ; Thu, 2 Jul 2020 07:40:03 -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 PhcsN40yp3Gq for ; Thu, 2 Jul 2020 07:40:01 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2064.outbound.protection.outlook.com [40.107.94.64]) (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 CC7653A0826 for ; Thu, 2 Jul 2020 07:40:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YFwb5T9Rcg72TtVDisN7USd/vUI0szlDzH4F0UepiSv58df3cwZKw1/MssrENFLe1zFmBpPVfcai2tL8DOLJhlS+/h1LkTP6M/CTxJPnOUlxfoKWmLG1q6Q4cA/gpMc045G00PhEIwDunNofCWdWoPggrQ6tV9HZPNH1uKcaFJbO8aqwplT9+9n0QL52aZXE6uKiXIMuvIu0Gq3qTklfd3uVdP9bqp1KV3uWqDcj1HQGMkreM5CSEAhOlu+yRaaklvtse1wpSfIkpylzbIiO7g00BaiEHiRy8MPybFQuXzSq3F/5TuhikRLEuf/xbWfaHP6ZNJ9ThYL7jk2ZssPBJw== 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=IVXkBL9AVM36050g/ZOrg4s0Gk+vuJmMCVhla0en+Co=; b=JknpKWlmk+/6zN5XrXqRY/jrJ7xnS6mzlbfak3L4V0Q9Z5tcVZe5F4j2K9HcS97D5NHdcopRJGiKE7nQL7TYGdp1ncIpDilseug2NesIW+4BR+xH/Kf60FC2v8Q00uCXOOfIAaD1doP/O2wuuEa5pO/bl9k5JK16escPtWiGujPDKbLwm3P6qGqMhxk9jIyc8yvMGZV/ofXAJDzeIg3HAagABvgFe2uQFz6Xaq5obmBtYShz5JPiXM6AgZEgNAMiVJU86gHkIxfanBx6HgpQpNDuUOP1WaD2vKYC3DhKQQSF/MXqRlyhPFiPowvcoTtVSLsGejnuur9CGjdtzBV75Q== 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=IVXkBL9AVM36050g/ZOrg4s0Gk+vuJmMCVhla0en+Co=; b=QpkRnRnxrgAK6eNEB6M0qS/VveMrpV2lSSIaLEJgBtrmv8L8+U1yiMlRZZMnAZEhzywZO5N9DL9RqpKsrAxkTB5R5oAmbkB12ieL+9D6U3nj93c6dqFM5ZvZXKynSRO3YHpRG5PjV2+jK6f8Kfnqrhh+B1xjjb6f4gKOtoJl8W8= Received: from BL0PR02CA0106.namprd02.prod.outlook.com (2603:10b6:208:51::47) by BN8PR12MB3410.namprd12.prod.outlook.com (2603:10b6:408:45::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Thu, 2 Jul 2020 14:39:59 +0000 Received: from BL2NAM02FT044.eop-nam02.prod.protection.outlook.com (2603:10b6:208:51:cafe::40) by BL0PR02CA0106.outlook.office365.com (2603:10b6:208:51::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.21 via Frontend Transport; Thu, 2 Jul 2020 14:39:59 +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 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.3153.24 via Frontend Transport; Thu, 2 Jul 2020 14:39:58 +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 062Edubj032418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jul 2020 10:39:57 -0400 To: OKUMURA Shinji , sipcore@ietf.org References: <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> <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> <9571d4c4-8478-98db-43cc-93dce969f142@alum.mit.edu> From: Paul Kyzivat Message-ID: <2e58147f-6de8-c1af-7d7b-e6b0d57a6a6b@alum.mit.edu> Date: Thu, 2 Jul 2020 10:39:56 -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)(396003)(136003)(376002)(346002)(46966005)(186003)(2906002)(5660300002)(83380400001)(966005)(478600001)(7596003)(31696002)(82310400002)(86362001)(2616005)(956004)(356005)(15650500001)(336012)(30864003)(82740400003)(75432002)(8676002)(70586007)(786003)(31686004)(53546011)(316002)(8936002)(36906005)(26005)(70206006)(47076004)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aa1fd58a-4766-4672-2ec7-08d81e95cb6a X-MS-TrafficTypeDiagnostic: BN8PR12MB3410: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0452022BE1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +yrl1+E+IXLHBHbIODJzV3ja/xB2pPWylVr+8pjIxorvgQDKapE7tGWiEl9E2g7wRE1IQDP1CQ6mrmYMOT9YcEuPathkr0TX0ngts984Dq6OPOKky6Twm379ie5Oj9Dl5H+mD4SB1Xx26qqP+XTcwbLZgeHfIXWvA8bBO07UdDSTko2NOrsnmCtRkGhmYOB2mGvBVxrcz/2NrqXbEG3YA0GS5LI/u0GeLClNAO9KzLOMUPtVWR2oirTIBInT1tpqHgpsdkgWfCfYNLqzK6y3asgz9KoXdBvZnR3BHa/FH11rycxLhqWgo/2Uw6D7E7w1WAs+rKgudLwq+EN91mi0E9lb/QQ3yeMeUz1ykbKUCgnfsw9h8XkJd7OYc2nP4r7ko0pdHEaekSFZF41mSOW70uGNkWePtBLZe2dQYDxqHaF/xT/byuJWhJxqp2Fq0+l6NPQQfFZScwfSsg68ADhgxTsaXYjehWuhjXshUvvjoFICiq8ycH5mGp8Pg6GjkcwS X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2020 14:39:58.3999 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa1fd58a-4766-4672-2ec7-08d81e95cb6a 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: BN8PR12MB3410 Archived-At: Subject: Re: [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: Thu, 02 Jul 2020 14:40:04 -0000 On 7/2/20 1:35 AM, OKUMURA Shinji wrote: > Hi, > > UPDATE and PRACK transactions perform SDP negotiation, session timer > negotiation, etc., but also have the function of indicating the target > URI and confirming the provisional response. A 200 OK is interpreted as > a success response for all meanings, but we sometimes want to reject a > part of them. > > I think that new header can specify the intended function in the request > or the unintended function in the response. > > This is what I'm currently thinking about. Hmm. Are you thinking of using the header with a 200 response, so that the transaction succeeds while still signaling that some aspect failed? Or using it with a failure response to identify what aspects failed? (So that a retry might fix the bad part while leaving other parts alone.) I'm interested to hear what others think. This wouldn't be hard to add. But the logic to act on the receipt of this header could be quite complex. Thanks, Paul > Regards, > Shinji > > On 2020/07/02 0:54, Paul Kyzivat wrote: >> On 6/30/20 8:49 PM, OKUMURA Shinji wrote: >>> 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. >> >> Can you say more of what you are thinking? >> >> I was only suggesting an option tag that indicates support for the >> revisions in this bis. That gives a little more flexibility in how >> things work. It sounds like you something more specific in mind. >> >>      Thanks, >>      Paul >> >> >>> 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 >> From nobody Thu Jul 2 08:29: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 000253A0A86 for ; Thu, 2 Jul 2020 08:29: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 OaJEQq0n2WA2 for ; Thu, 2 Jul 2020 08:29: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 4F06C3A0953 for ; Thu, 2 Jul 2020 08:29:24 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id x83so16436118oif.10 for ; Thu, 02 Jul 2020 08: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=tVMPW2tIa6eUMbuzlCxE+Ix4Yf3Dr1B9VPIAY+GcDD0=; b=BQy0cGQl3ucIVtrgG/pfsW07h7A7U+stgaPbq3b/CHZeN+GZHBPhWiysYz+Atp71PA hFwA0mTxMNAA+CRbZwR0tQ1KIq4FPmflqo8umHfiYIeYBX3BhiEnFgxQqizoIafnHgbR wRTuGR74Xuel4BX6Qsf6V2Gj8qpQgoHhzmo8DGFtWQd+XaIaVbXqudX4hzI5Wo0fDeYQ kH84hlqsFa4ScXDjJzk3QSmRu7vHq5WxhmZsz+h8v/d71lJ1Anj0TwprK7TeTytNP6g4 QH1cEn8jRAa3Y1bcqahtrrSSI0jR/j/6BXcbCKT7K4qmjjZWtaP1aruSNL918K1IFlsQ AMkg== 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=tVMPW2tIa6eUMbuzlCxE+Ix4Yf3Dr1B9VPIAY+GcDD0=; b=dGWD8RPSH9XhNNqaE6aw/+l3/ZED2LS9b/QEklyIZi3IdJx7iBhMmA3Yn1J0VmmopZ +Ac+bYn3/isoOnJcIqsiVaFLtDTeC9yoRs9QmJcVBr4IgyDTkKkdMajd7iux9bNP6Ule YVceuG2tt+/Mo7z2jLrMOPgQeSH73RZOQn2Xwuvq4CoK1bK9Rfe7+zIu8uyC16opBUWB VFH00Ioz3brahz2H3e4nHB9WKZVhPuGUwVXqNykkz3XoK3G5VGs7lnqL7eKrwE3/9VNY 3quPY7oQycmm0UXUU0gwBPdo0KoawuiLGZP5SSvHICtm9iRzsrgkQ2oQk+qBk1/3wXcV bm2w== X-Gm-Message-State: AOAM530xEw5a/tdQvpm5QuJOGPs8hrAkyDGTfajBo1MuFYqSsk1xwTwJ u8OV2wRR3ZzmqDb8CU6swEV7A8qCY2I= X-Google-Smtp-Source: ABdhPJzBcyBpmXGiPH16nJQLQrYdE5Yw9ketTD8HhJgVlJ+5CklQT3C2vmiwe5kjkjoUn+kjjqO1oQ== X-Received: by 2002:aca:da44:: with SMTP id r65mr23666379oig.124.1593703763634; Thu, 02 Jul 2020 08:29:23 -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 f83sm2647008oib.11.2020.07.02.08.29.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 08:29:22 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id 18so24416963otv.6 for ; Thu, 02 Jul 2020 08:29:22 -0700 (PDT) X-Received: by 2002:a05:6830:1db9:: with SMTP id z25mr368906oti.13.1593703762362; Thu, 02 Jul 2020 08:29:22 -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> <74ff2b78-9251-8018-7a37-ffcf2edc20cc@alum.mit.edu> <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> <9571d4c4-8478-98db-43cc-93dce969f142@alum.mit.edu> <2e58147f-6de8-c1af-7d7b-e6b0d57a6a6b@alum.mit.edu> In-Reply-To: <2e58147f-6de8-c1af-7d7b-e6b0d57a6a6b@alum.mit.edu> From: Roman Shpount Date: Thu, 2 Jul 2020 11:29:11 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: OKUMURA Shinji , SIPCORE Content-Type: multipart/alternative; boundary="000000000000a2067405a977125a" Archived-At: Subject: Re: [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: Thu, 02 Jul 2020 15:29:50 -0000 --000000000000a2067405a977125a Content-Type: text/plain; charset="UTF-8" Paul, I can see how we can add a new option timer2 tag and include it in negotiation. If UAS sees a Supported: timer2 in the INVITE/UPDATE, and it supports the new procedures, it must include Require timer2 in the response. This will indicate that both UAS and UAC follow the session timer procedures in the new draft. The new timer2 can be included in parallel with the existing timer option tag. _____________ Roman Shpount On Thu, Jul 2, 2020 at 10:40 AM Paul Kyzivat wrote: > On 7/2/20 1:35 AM, OKUMURA Shinji wrote: > > Hi, > > > > UPDATE and PRACK transactions perform SDP negotiation, session timer > > negotiation, etc., but also have the function of indicating the target > > URI and confirming the provisional response. A 200 OK is interpreted as > > a success response for all meanings, but we sometimes want to reject a > > part of them. > > > > I think that new header can specify the intended function in the request > > or the unintended function in the response. > > > > This is what I'm currently thinking about. > > Hmm. > > Are you thinking of using the header with a 200 response, so that the > transaction succeeds while still signaling that some aspect failed? > > Or using it with a failure response to identify what aspects failed? (So > that a retry might fix the bad part while leaving other parts alone.) > > I'm interested to hear what others think. This wouldn't be hard to add. > But the logic to act on the receipt of this header could be quite complex. > > Thanks, > Paul > > > Regards, > > Shinji > > > > On 2020/07/02 0:54, Paul Kyzivat wrote: > >> On 6/30/20 8:49 PM, OKUMURA Shinji wrote: > >>> 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. > >> > >> Can you say more of what you are thinking? > >> > >> I was only suggesting an option tag that indicates support for the > >> revisions in this bis. That gives a little more flexibility in how > >> things work. It sounds like you something more specific in mind. > >> > >> Thanks, > >> Paul > >> > >> > >>> 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 > >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000a2067405a977125a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

I can see how we can add a new op= tion timer2 tag and include it in negotiation. If UAS sees a Supported: tim= er2 in the INVITE/UPDATE, and it supports the new procedures, it must inclu= de Require timer2 in the response. This will indicate that both UAS and UAC= follow the session timer procedures in the new draft. The new timer2 can b= e included in parallel with the existing timer option tag.
_____________
Roman Shpount


On Thu, Jul 2,= 2020 at 10:40 AM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 7/2/20 1:35 AM, OKUMURA Shinji wrote:
> Hi,
>
> UPDATE and PRACK transactions perform SDP negotiation, session timer <= br> > negotiation, etc., but also have the function of indicating the target=
> URI and confirming the provisional response. A 200 OK is interpreted a= s
> a success response for all meanings, but we sometimes want to reject a=
> part of them.
>
> I think that new header can specify the intended function in the reque= st
> or the unintended function in the response.
>
> This is what I'm currently thinking about.

Hmm.

Are you thinking of using the header with a 200 response, so that the
transaction succeeds while still signaling that some aspect failed?

Or using it with a failure response to identify what aspects failed? (So that a retry might fix the bad part while leaving other parts alone.)

I'm interested to hear what others think. This wouldn't be hard to = add.
But the logic to act on the receipt of this header could be quite complex.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> Regards,
> Shinji
>
> On 2020/07/02 0:54, Paul Kyzivat wrote:
>> On 6/30/20 8:49 PM, OKUMURA Shinji wrote:
>>> Paul,
>>>
>>>> I think this probably suggests that an option tag for supp= ort of the
>>>> updated ST draft would be helpful.
>>>
>>> Defining a new header that limits the double-meaning of a tran= saction
>>> may be useful for other issues.
>>
>> Can you say more of what you are thinking?
>>
>> I was only suggesting an option tag that indicates support for the=
>> revisions in this bis. That gives a little more flexibility in how=
>> things work. It sounds like you something more specific in mind. >>
>> =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/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 receiv= es a session
>>>>>> refresh request during another session refresh tra= nsaction, 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&#= 39;t have to worry
>>>>>> that my desired implementation is a protocol viola= tion, right?
>>>>>
>>>>> I'm sure there are situations where the two ends c= an arrive at a
>>>>> common understanding without raising the 491. But I th= ink the
>>>>> complexity of spelling out the cases so things are det= erministic 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 wit= h an older
>>>> implementation that doesn't do that.
>>>>
>>>> If we have one UA supporting the extension and one that do= esn'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, the= n the 491
>>>> would not be used by either end in ST glare cases, and eve= rything
>>>> 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 al= so 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 o= ptional,
>>>> 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 supp= ort 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 refres= h that Shinjit was
>>>>>>>> raising is not new. It affects session des= cription updates as
>>>>>>>> much as it does session timers.
>>>>>>>>
>>>>>>>> Second, I am not sure there is an actual p= roblem. Target refresh
>>>>>>>> is done via a SIP transaction, so it does = not happen
>>>>>>>> instantaneously. SIP transactions=C2=A0can= be delayed due to proxy
>>>>>>>> processing or network delays, as well as d= ue to a packet loss.
>>>>>>>> The delay introduced by 491 error response= is generally
>>>>>>>> comparable to transaction delay, so it nor= mally does not
>>>>>>>> introduce any new problems. All that shoul= d happen due to a 491
>>>>>>>> response, is that the transaction should b= e retried with some
>>>>>>>> delay and target refresh should happen sli= ghtly later.
>>>>>>>>
>>>>>>>> Considering that this is an existing desig= n 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 reaso= ning for purposes
>>>>>>> of the discussion. I'm inclined to agree t= hat 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 a= ppropriate.
>>>>>>>
>>>>>>> It isn't strictly backward compatible. But= if a UAS uses it, I
>>>>>>> bet there is a pretty good chance that a UAC r= eceiving the 491 in
>>>>>>> that context will do the right thing, or at le= ast something
>>>>>>> reasonable, 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 Kyziv= at
>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>= wrote:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 ISTM that the key issue= Shinji is raising is that it could be
>>>>>>>> =C2=A0=C2=A0=C2=A0 problematic to raise an= error to an UPDATE that is doing a
>>>>>>>> target
>>>>>>>> =C2=A0=C2=A0=C2=A0 refresh. This is true r= egardless of what else the UPDATE is
>>>>>>>> doing - an
>>>>>>>> =C2=A0=C2=A0=C2=A0 offer, session timer re= fresh, or maybe nothing else.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 The bottom line here is= that if you have an urgent need to
>>>>>>>> do a target
>>>>>>>> =C2=A0=C2=A0=C2=A0 refresh, you should do = it with a request 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 a= n UPDATE, and in conjunction with a
>>>>>>>> session time
>>>>>>>> =C2=A0=C2=A0=C2=A0 refresh (and/or offer) = then it should be prepared for the
>>>>>>>> consequences
>>>>>>>> =C2=A0=C2=A0=C2=A0 if the UPDATE is reject= ed (with 491 or anything else.)
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 I guess we could discus= s how much (if any) of this logic
>>>>>>>> ought to be
>>>>>>>> =C2=A0=C2=A0=C2=A0 included in the documen= t.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 I don't think this = alters the validity 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 Thanks,
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Paul
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 On 6/24/20 3:19 PM, Rom= an 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 <mailt= o:ietf.shinji@gm= ail.com>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:<= a href=3D"mailto:ietf.shinji@gmail.com" target=3D"_blank">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 timer 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 UPDATE 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 state 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 timer state in this case is to refuse the
>>>>>>>> UPDATE message,
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0= =C2=A0similar to 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 discu= ssed 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, the 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 combined, 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 rarely 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 the 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 rejected, 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=A0= This should be no 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 wha= t problem you are 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 > This is exactly the reason why handling of UPDATE
>>>>>>>> transaction
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0= =C2=A0collisions 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 collision.
>>>>>>>> =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=A0collisions on retransmission. And we also need to
>>>>>>>> decide how UAs
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0= =C2=A0detect collisions.
>>>>>>>> =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 sur= e what you are talking about.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > ____________= _
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > Roman Shpoun= t
>>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> = sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listi= nfo/sipcore
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipc= ore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/= sipcore
>>

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000a2067405a977125a-- From nobody Thu Jul 2 10:20:04 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 4DFBD3A0B81 for ; Thu, 2 Jul 2020 10:20:02 -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 aacq-zN6pLnu for ; Thu, 2 Jul 2020 10:20:00 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E7B3A07C7 for ; Thu, 2 Jul 2020 10:20:00 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id k6so20386840oij.11 for ; Thu, 02 Jul 2020 10:20:00 -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=qMFu+2STGI6vu7PCdIkRJZLXGUqAPXVkjOtzc6tZTS4=; b=s02RqjUky0/Mp2FEm/7Z/OuPLhCeE0Uz6kZ2NrGxlLWezsT72TL3Kmar6oalatWkAh AJ1GwRkjkWYmfPBsXWLLz6S0MN53nLcLoMAeVVNDdPzCuMyAYZQgNvx5CrCk00J1vrRN EABg+ENF3DY0CxfsjKjykD0DpGqU+rxT+hHzqeoamFEyzKxBGJuwH+hL6tOfh4zlFR78 lg/ygsHubeh6hRCJMN9dI8E92hZ4Ww4H4O27AeZifFENgExYsqOB7U49HAvE7eXmYNCr oTJiLNMiehowKUDew7CO1IWgBYG3lzXCq1U6CF0xPjd335jhC2JshkZxveNpLpOZ2vYL ty/Q== 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=qMFu+2STGI6vu7PCdIkRJZLXGUqAPXVkjOtzc6tZTS4=; b=NhxwzmxEAj/zELvoUwUitnRjWUG9VHMXzgSLRKxC7aS2Iq0PxJ6xO4jz6hBZkHgHPc pzM4//Gpqb2WAeW1TnkA9kWd8efTPLtx5Cba3qcNxA2Kuwz/Wn7tJT+WnjWfWml7pD0s 1xKuJfAg1hCcco76JZ8k+cN0GDabo2EQ/mQy3hZv0p7szJEt5ohIoEQuFGLyehNAKyk1 /nouxAd9RHS/2kdHgJZFFVD07hJChBTbMBEC8hYhaCwPP2ccHHXgTKDOtV39GsoLeGsV t1/rin2D1YxMv7NGsjPZRTG2e0OX96tpcqNWlvSIUsCQG1DOADStwDFKJ1Ib6azCdx4+ eEeA== X-Gm-Message-State: AOAM531oeUORjoS3jb4s5ecSEiKXvWeaLpuH9lXvHbtNwcuzTuWBUXri 2bkylDXRHzZNu1VRmCaxhRt63QxY4IQ= X-Google-Smtp-Source: ABdhPJyIqacR4kIvIYUq1W7Y5ppkxHjkRDCPjlQ8VNugO0q0dxObABryWLpBFdHPmH5IlyWJ/MPa8g== X-Received: by 2002:a54:408f:: with SMTP id i15mr23374683oii.70.1593710399104; Thu, 02 Jul 2020 10:19:59 -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 x2sm2702658oig.8.2020.07.02.10.19.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 10:19:58 -0700 (PDT) Received: by mail-ot1-f52.google.com with SMTP id w17so16841454otl.4 for ; Thu, 02 Jul 2020 10:19:58 -0700 (PDT) X-Received: by 2002:a9d:7545:: with SMTP id b5mr11579995otl.19.1593710397899; Thu, 02 Jul 2020 10:19:57 -0700 (PDT) MIME-Version: 1.0 References: <3688f589-d467-2144-0fae-6229266af109@gmail.com> In-Reply-To: <3688f589-d467-2144-0fae-6229266af109@gmail.com> From: Roman Shpount Date: Thu, 2 Jul 2020 13:19:46 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002448fd05a9789ec0" 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: Thu, 02 Jul 2020 17:20:02 -0000 --0000000000002448fd05a9789ec0 Content-Type: text/plain; charset="UTF-8" Shinji, I am going to ask, once again, is this a problem which affects anybody? I would still argue that this is not a real security problem and should be left as is. _____________ Roman Shpount On Wed, Jul 1, 2020 at 4:40 AM OKUMURA Shinji wrote: > Roman, > > I first suggested how the UAC would use the maximum value of MSE. How the > UA knows the maximum MSE is the next topic. > At least a caller UA knows its own MSE. And the UA may receive a session > refresh request, even if it is refresher. However it is a passive event, it > doesn't happen for sure. > > Q. How does a UA know the correct maximum value of the Min-SE? > > A1. When a dialog is established, both UAs send a session refresh request > with its own Min-SE. However, regulations are needed to prevent them from > sending at the same time. > > A2. When a dialog is established, either UA sends a session refresh > request with its own Min-SE. And the UAS return Min-SE in 2xx. > > In either case, UA may receive 422 responses, but only once. > > Regards, > Shinji > > On 2020/07/01 2:22, Roman Shpount wrote: > > 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 > > > --0000000000002448fd05a9789ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shinji,

I am going to ask, once again, is this a problem which affects any= body?

I would still argue that this is not a real = security problem and should be left as is.=C2=A0
_= ____________
Roman Shpount


On Wed, Jul 1, 2020 at 4= :40 AM OKUMURA Shinji <ietf.shi= nji@gmail.com> wrote:
Roman,

I first suggested how the UAC would use the maximum value of MSE. How the U= A knows the maximum MSE is the next topic.
At least a caller UA knows its own MSE. And the UA may receive a session re= fresh request, even if it is refresher. However it is a passive event, it d= oesn't happen for sure.

Q. How does a UA know the correct maximum value of the Min-SE?

A1. When a dialog is established, both UAs send a session refresh request w= ith its own Min-SE. However, regulations are needed to prevent them from se= nding at the same time.

A2. When a dialog is established, either UA sends a session refresh request= with its own Min-SE. And the UAS return Min-SE in 2xx.

In either case, UA may receive 422 responses, but only once.

Regards,
Shinji

On 2020/07/01 2:22, Roman Shpount wrote:
> 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 po= ssible to enforce this rule. Otherwise, the value Min-SE set by the proxy a= nd 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 <mailt= o:ietf.shinji@gm= ail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Since the subject and the discussion have diverged,= I will sort out the topic once again.
>
>=C2=A0 =C2=A0 =C2=A0The issue I raised:
>
>=C2=A0 =C2=A0 =C2=A011.=C2=A0 Security Considerations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Next, consider the case of a rogue U= AS that wishes to force a UAC to
>=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 support session timer.=C2=A0 The ini= tial INVITE arrives at the rogue UAS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which returns a 2xx with a very smal= l session interval.=C2=A0 The UAC uses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this timer and quickly sends a refre= sh.=C2=A0 Section 7.4 requires that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the UAC copy the current session int= erval into the Session-Expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 header field in the request.=C2=A0 T= his enables the proxies to see the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current value.=C2=A0 The proxies wil= l reject this request and provide a
>=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 that if the proxies did not reject t= he request, but rather proxied
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the request with a Min-SE header fie= ld, an attack would still be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possible.=C2=A0 The UAS could discar= d this header field in a 2xx response
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and force the UAC to continue to gen= erate rapid requests.
>
>=C2=A0 =C2=A0 =C2=A0If the rogue UAS returns again a 2xx with a very sm= all session interval, the attack will continue.
>
>=C2=A0 =C2=A0 =C2=A0My suggestion:
>=C2=A0 =C2=A0 =C2=A0The 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 M= SE-value, then the UAC should consider the SE-value as the maximum MSE-valu= e.
>
>=C2=A0 =C2=A0 =C2=A0Other suggestion:
>=C2=A0 =C2=A0 =C2=A0The UAC should immediately terminate a call.
>
>=C2=A0 =C2=A0 =C2=A0How is it?
>
>=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
>
--0000000000002448fd05a9789ec0-- From nobody Thu Jul 2 18:41: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 EE92F3A0AA6 for ; Thu, 2 Jul 2020 18:41:54 -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 k8ydkELphv_V for ; Thu, 2 Jul 2020 18:41:53 -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 C25E43A0AA4 for ; Thu, 2 Jul 2020 18:41:53 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id t11so8444445pfq.11 for ; Thu, 02 Jul 2020 18:41:53 -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=dwM7kMNQ2oxxeGxHkj7zvuIRpV8jOYjD4CDMrgDv4Nw=; b=apXrQ0idTyuBDHpmIvTq63FMD3/+LUTimchZewUSTZj6ihgmvUy7s5xMku+6puNq0B b7vPaMH4+TYZYaM7NxIKWRv/Mwe2QDmpSGSjubAw169LWN0QVMn9PqQUPMK1W1nIarIz lsP+g2cNvzTJ/FWvyKyETd/ygXnyZaw+9XtZqUcM69Qxz6VxlnjmdeD8RMniCUJeA8Fh Dz1jjH/K24ASo0cQBOsDm4MHsgHWZwXPeUUPFPv24hKlJlS505jMdR9h9AKfcBTZV5LV Eeeq2r5hRjVlY7DhUXWeEfEFGuXz5B0yGEZ52ltaFp3EswM3jQ2SQSEAXqZIEHXl0ps8 44tA== 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=dwM7kMNQ2oxxeGxHkj7zvuIRpV8jOYjD4CDMrgDv4Nw=; b=GBp2dfFlRZiByVpz9pRz92uXWrGqopcwl6g3944oPR7uIGOVuI8BbQei/LHxieI8Td lryMAEz/t8zGqR+iDyUvUwTMM3DYFRlVk3vtq1nlMW3YTvFwfJ8Qfe4XLQWoLCckikGH K/fNQ3sKLHRPX1NTY6BrMA1uU43ZnoiUZ70eIeeIto7+gYVhugajEFgHv2wWoZ37PGgI LIk2xG46tCVCvHAPMsM7e2lcWrBybtNPaDm8f2n53FrbeO8lfXvkeqRCiF1y6KHwwZzs aEg/YUCc+cNCD2A06czdlf0LMuy4wvccKls3QS7ZUss//JEgQYgIbaECt544GCfE0R49 i+ig== X-Gm-Message-State: AOAM533M4IHrXoYGKQd2qaApy9mWgDSb/o/stiErWUPkV4DxNypR2Enb bQUDmAyCBThVucai30E+C3I= X-Google-Smtp-Source: ABdhPJz0k2Oxx3YKug9HL55w64T/p6tk2eQ01/r18xVcBCfIQ2MjW2oePdezyOVDYYBav0fGusEwHg== X-Received: by 2002:aa7:9736:: with SMTP id k22mr29980251pfg.62.1593740513056; Thu, 02 Jul 2020 18:41:53 -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 z1sm9690854pgk.89.2020.07.02.18.41.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 18:41:52 -0700 (PDT) To: "sipcore@ietf.org" Cc: Roman Shpount References: <3688f589-d467-2144-0fae-6229266af109@gmail.com> From: OKUMURA Shinji Message-ID: <58cd1684-518c-aae1-e95c-b127651d4031@gmail.com> Date: Fri, 3 Jul 2020 10:41:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 : 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: Fri, 03 Jul 2020 01:41:55 -0000 Roman, This problem was originally listed in RFC4028. I am proposing an amendment because I believe the solution described in the RFC is inadequate. Are you thinking that my claim that the RFC-listed solution is inadequate is wrong? Or are you arguing that it's inadequate but not necessary to fix it? Regards, Shinji On 2020/07/03 2:19, Roman Shpount wrote: > > I am going to ask, once again, is this a problem which affects anybody? > > I would still argue that this is not a real security problem and should be left as is. From nobody Thu Jul 2 21:48: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 819023A0C74 for ; Thu, 2 Jul 2020 21:48: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 slIOoIWjeFMO for ; Thu, 2 Jul 2020 21:48:21 -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 9B2433A0C70 for ; Thu, 2 Jul 2020 21:48:21 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id c1so6197010pja.5 for ; Thu, 02 Jul 2020 21:48:21 -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=Cr1guXqStnUwkmZS6IEzRqyr2lbFzyTN7e2K9llDRXg=; b=JWbStBvgaTriWYaRzolhhUAOYuFTW6Jc48jJpMMpxH+u9ZKZDE4erUU9x4ea7iomL8 o6axUT5Jv14WzmOVbhqhbKG3X6q8A5i9C2IK4OPZmwIVoyJCXZ0apmldJSPp74yC7o1o 0sl0tn+pUWefJ8NHWy+YeO3HC0YT/hbNwwJ41ryfSG9rwcTGy+6OnLtDbwRoF6syobRk 9I4cuAb1agC/LkCc5ZkCa8yU8yXSsX4Jov2G/BzEsP0jc4SXWdbORTGj20Gsx3zbLd7+ gpewgo8oIUnXJa1qXAFSgm0lAlFbRM1w9SEENxM5XISPtlfMuFDe588lfm1YRZIW2WOe sQ0g== 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=Cr1guXqStnUwkmZS6IEzRqyr2lbFzyTN7e2K9llDRXg=; b=CIDhj9n9C/P256vEO7ktLtUH+iWLG9BNWMmmRdl/iyjqcZk6aVDa/Gz2zVjVpyvUTx +uNbe8JGHn4a0OVAUGetzw02IZ8D4uw70jqSW8UT2iH+zAFcLzBIHwSD3eshvOB1aZ8F HAH+78sTNH2NjIdSYlpig3e/6mbalKBoTv4ZBVc/vojCh+nW2qbgjLD1/CAquociL6Tl Fc5NNcltYAFBeLM/LtxZHbDfr0aXPglfSfarAhXVqF53+tn/ME0uhROVoGYmzxSKJuED WAMvz1/h0bYBnq9UEE07ljogiv8fPac/4V75UnnWalXLoYtOEFeoCYBmMRThZt8OQGjq HJ1w== X-Gm-Message-State: AOAM530ueO6rrf4DQaPnbsBS3DEVKYWnfWoonY0krBUe0zs++h3S7y6G x+DTwKre5jotvhZe0YHikuk= X-Google-Smtp-Source: ABdhPJwvVxgKR6ehY82nF24oAgwU1MIOwHxq5/o0G8vsP9++8M1lBTpziLSfIGAZ/MZ/N9qFlwPSLw== X-Received: by 2002:a17:90a:e60b:: with SMTP id j11mr37270426pjy.189.1593751700962; Thu, 02 Jul 2020 21:48:20 -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 f131sm10406142pgc.14.2020.07.02.21.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 21:48:20 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org References: <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> <828031fd-1699-bac3-7f0d-7b8acf532b64@gmail.com> <9571d4c4-8478-98db-43cc-93dce969f142@alum.mit.edu> <2e58147f-6de8-c1af-7d7b-e6b0d57a6a6b@alum.mit.edu> Message-ID: Date: Fri, 3 Jul 2020 13:48:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2e58147f-6de8-c1af-7d7b-e6b0d57a6a6b@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] 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: Fri, 03 Jul 2020 04:48:24 -0000 Paul, > Are you thinking of using the header with a 200 response, so that the transaction succeeds while still signaling that some aspect failed? For a 200 response, Yes. About session timer, this header means that I(UAS) respond 200 but didn't agree about a session timer . > This wouldn't be hard to add. But the logic to act on the receipt of this header could be quite complex. I agree. It might not be so good. Regards, Shinji On 2020/07/02 23:39, Paul Kyzivat wrote: > On 7/2/20 1:35 AM, OKUMURA Shinji wrote: >> Hi, >> >> UPDATE and PRACK transactions perform SDP negotiation, session timer negotiation, etc., but also have the function of indicating the target URI and confirming the provisional response. A 200 OK is interpreted as a success response for all meanings, but we sometimes want to reject a part of them. >> >> I think that new header can specify the intended function in the request or the unintended function in the response. >> >> This is what I'm currently thinking about. > > Hmm. > > Are you thinking of using the header with a 200 response, so that the transaction succeeds while still signaling that some aspect failed? > > Or using it with a failure response to identify what aspects failed? (So that a retry might fix the bad part while leaving other parts alone.) > > I'm interested to hear what others think. This wouldn't be hard to add. But the logic to act on the receipt of this header could be quite complex. > >     Thanks, >     Paul > >> Regards, >> Shinji >> >> On 2020/07/02 0:54, Paul Kyzivat wrote: >>> On 6/30/20 8:49 PM, OKUMURA Shinji wrote: >>>> 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. >>> >>> Can you say more of what you are thinking? >>> >>> I was only suggesting an option tag that indicates support for the revisions in this bis. That gives a little more flexibility in how things work. It sounds like you something more specific in mind. >>> >>>      Thanks, >>>      Paul >>> >>> >>>> 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 >>> > From nobody Thu Jul 2 22:13: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 D0A8D3A0CB1 for ; Thu, 2 Jul 2020 22:13:49 -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 Be-Um_hJ45AJ for ; Thu, 2 Jul 2020 22:13:48 -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 F0B963A0CAF for ; Thu, 2 Jul 2020 22:13:47 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id e18so14559528pgn.7 for ; Thu, 02 Jul 2020 22:13:47 -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=u6rDeMGYkJ4JlgMD8Ug9yXPu6GNKlCsu/dFi5DAV2P8=; b=k8ydhJFO6HxnlWSoKiwItPqYmDMP0avAaMrY5GaJPurtwe7wLZ5Ch7xr14yDcVjg10 HD3WoK9oLLCeC0/SemgfvRJZpumy67avICpg26eL0QoxOpdWSGc+FVu4rd4mfVSfr90N YLpO/IkVLVTVaSuiFHJYXKfSfVr/I0/prdH5ZDWqH9/AWM4MUk+2KUHs4GF8ms1lAmA3 2ONciLwW/eceTSEcivpKAKrWWQwMjG+BUOO3TGffru4EC9Dky/SZ6hXGAHMB2vtlAUhq bJOYJWuO8eeO028RRtjRWfDnIjfxpGBEBOcM/icL6z4Pe29tViyIPQB1dk3YlAJ6VP/2 Hz+w== 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=u6rDeMGYkJ4JlgMD8Ug9yXPu6GNKlCsu/dFi5DAV2P8=; b=k8XY1BUmUGYk7f2Farz/rncVNyxTjojfzd+MtFoTKaYw/9ECNpMsfugSelKmXldQdf JfenmIhynJBYzdquCWEh5iGjTuTYWkYwwJbmevc9XDtuZtCAhTvm/2fo+bt8SAMlXFvI S8B07WJBEQQE8RC/3E3/I+euCPD56MTOHWCV68H8uNlMUEMu2Icxz1gi6PrU175iMGo9 Bxfx1hzAH9yJKDaSDWIdYaX3q9KuMD6i4fz7qy7eyXwCSHETs3QpmbewapbohMLASrk7 yLvYY0x1SIdukr5LzGJIZPkY0Z3a4KX1P4/xTIphSbslZQsmU6yP/rUVe8zEb4zSt66E Cnew== X-Gm-Message-State: AOAM531QmuDXPo1qy8/UXHT8UroRSLRqWDNtJX9fE79PsHUp5dy5W2U4 19IgdY28o37qAFpbtzq1xQ9JuD10 X-Google-Smtp-Source: ABdhPJw3XVAwfUq3TLPoHcAhRqDBAG3fhYdZ+yMGvWtgUAiR7v0bg4Ssk5b8U5iqCxhuQQ6kVaEjBw== X-Received: by 2002:a62:8848:: with SMTP id l69mr26423399pfd.314.1593753227194; Thu, 02 Jul 2020 22:13:47 -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 g3sm10131033pfq.19.2020.07.02.22.13.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 22:13:46 -0700 (PDT) From: OKUMURA Shinji To: 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> Message-ID: <3d6bc669-5dc0-e75e-c99f-903d0aed3e8d@gmail.com> Date: Fri, 3 Jul 2020 14:13:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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: Re: [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: Fri, 03 Jul 2020 05:13:50 -0000 Paul, If we use the 491 response to solve this issue, we might have to update the RFC 3311. Because this solution changes the way UAs treat UPDATE in general, not just session timer. 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 From nobody Fri Jul 3 00:28:49 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 7C59B3A0DE4 for ; Fri, 3 Jul 2020 00:28: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 eIPkVfrJ8cm1 for ; Fri, 3 Jul 2020 00:28:46 -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 77DAE3A0DDC for ; Fri, 3 Jul 2020 00:28:46 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id e8so14722932pgc.5 for ; Fri, 03 Jul 2020 00:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=P/oO6oL3/hJez5AYXkn8sGO0i9lZvSJTx21Uq775C/E=; b=CbKygzjezaiWcMvcRLRS+P8Kti8V8iJSS8XRWA39E875YrOWT+iZ8ur3y8v0pHUA/0 sK7J1QyVD2kfg6FTQvxEosGN7cnA/mBjI6KT37FIACo2V/wLIjTEyetkY2prDfqQrX0V ROUgugILm/UfE5NBpVbNKGOYlrmykzo1ihCRT9Goub/Q9R6MNRGVtbwOuPwbE17GrSGi byjdLDY3MaeetHHmFHsP3xayJIxBh+TP02FceRzogpj3xqDioQQpO/AywgrOPq2fUiJP aCZiT/eUNaAc/lx/2v0DjdtS36+4Qle4LKL5xUOQpRYwfMy32C/Skd4I4cC3BCZaX3eF EDwg== 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:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=P/oO6oL3/hJez5AYXkn8sGO0i9lZvSJTx21Uq775C/E=; b=HLU/2ugTppglPP++R42JPg3YbJsxQJnrkiHLWrALLI1lcF24sZd29/wxDJy8rdQaGb nvrEvU7xcg+PYBu34XOWCveetIXWlO/Mn8QhMJ4D4Uo3vu5gENZJ7JPsHrmGLVNRujDR kgZiH9hSkli/txhW9Xaxh47tAoEXy0pdUWgI9TnZaLS8JXN/yzMEpxF8c+gGb1LQeSE/ uiWOxs4BVRV5Eph7nYrSaUQApEG3agFxTdCk8RpCNsCqdUs8iR1yjvZqW6mztWeVdJ9D RnXans3TU5KW9/1YwX9eIditLL0ks3ZWxtS9ucWUFLHgREjeDTnmTINTbPgjP/Boy4PB 3WPg== X-Gm-Message-State: AOAM531zyB9Tuuvv4EXIRUKBwMUWx1BblMfwmow8lRlLINqCqQY5Xj/I 5Xdp+AZkJqncebPPWOpEUl6kddPp X-Google-Smtp-Source: ABdhPJyQoGtiBd5GtZAZYFn2lsI8NGjhrk062nDzSe8pGoNLe3UbxuCB2ZvotyW3ZLw7OU1lYlZuxg== X-Received: by 2002:a63:9247:: with SMTP id s7mr28804656pgn.355.1593761325453; Fri, 03 Jul 2020 00:28: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 h194sm10673516pfe.201.2020.07.03.00.28.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2020 00:28:45 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Message-ID: <5880dea8-91fb-ed5e-421c-047a6a6723e3@gmail.com> Date: Fri, 3 Jul 2020 16:28:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 : Ambiguous 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: Fri, 03 Jul 2020 07:28:48 -0000 Hi, ===================================================================== 8.1. Processing of Requests 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'. This is needed to protect against certain denial of service attacks, described in Section 11. ===================================================================== I'm suggesting amending the 1st sentence, but also the meaning of the 2nd sentence is unclear. ISTM the reason is not described in Section 11. Does anyone know the reason? Regards, Shinji From nobody Mon Jul 6 16:15: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 658DC3A0BE5 for ; Mon, 6 Jul 2020 16:15:14 -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 8IPalLj70nFE for ; Mon, 6 Jul 2020 16:15:13 -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 2D9473A0BE3 for ; Mon, 6 Jul 2020 16:15:12 -0700 (PDT) Received: by mail-oo1-xc34.google.com with SMTP id x2so639423oog.5 for ; Mon, 06 Jul 2020 16:15: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=GSXCEGdDkHjwEXIUvgwsIjXbV8wstuMGk3ZIhXRADnM=; b=sfwnVYMSLWpOo45P2/jPRZJcL741Wj1fqFdP7/m0aOVgjH4u04cqu+q3mFJs5tz0+8 qCPeXpj6fxtkA7TR7lE4h6BhJrtpwzFZMLskdEpKVaAjPYMSsMa+z3/JHdle/JEQvuFN FppWjk60oEWWLnFZXbhOBK3EBfr6vxE4OUcHUuiuQzTwOB+//zj8KKtg7o80NtHkfM+P qee0XkGjT4trdKp1rf+4sIjEknNY3bvkDnuZJgByiPVmlpy4lMwCwoUem9B5FFhaF/co TBYGlqF9yr26m3GKcU6fUAaBsJ3ccjpIbGKa2IH/8jcn3lEVuq4gNb14dI0WiTn7V6IK 229g== 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=GSXCEGdDkHjwEXIUvgwsIjXbV8wstuMGk3ZIhXRADnM=; b=DA2g4OTlrj67WaNwsl2pqwg1pJr71cw4SE1+urSW1rPtlH1rP8WDkWg4izztR9EPjx bYPBzzDo0vEYvSTySHqU1QBaNPbbEvSpQQSDxk2leXMErFTi8lUSIKUwmTfp6nduDtf9 jKhJroZzXPr1LorltryEVxbZbBA7c52cimMcmeb/Acc52CtdGnVUz4VVYz+WeaVFNXCa /PXYdgk3Jt86wzBc1iES2l+SzYG0W1FJCseVm+Ucr+vxgiiEt6okQDlhMKnqlPIsQ5Xv e6rN5U7DzsGxLftfFZlFhMzSvPuaixgCBklluehP+t/ObKKbm1cwC5lixQOSJTn1f1ET Qatg== X-Gm-Message-State: AOAM530X29c/wpW3IFw6OWRRdLI9VAow+S7yU+mdOQNP24HpBqfRs8Wh +4DlCw1BcfJG82jONFxstjkMUwxunxU= X-Google-Smtp-Source: ABdhPJzn88pM/bq4brn/YjmMSA0821IrLCbcfYqXFSjvkzzlU4ypiG0qJyaeVherHbrHGBzEHH4pXQ== X-Received: by 2002:a4a:980d:: with SMTP id y13mr44361042ooi.35.1594077311718; Mon, 06 Jul 2020 16:15:11 -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 t25sm5481714ots.64.2020.07.06.16.15.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 16:15:11 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id t18so20148826otq.5 for ; Mon, 06 Jul 2020 16:15:10 -0700 (PDT) X-Received: by 2002:a05:6830:1db9:: with SMTP id z25mr15927016oti.13.1594077310564; Mon, 06 Jul 2020 16:15:10 -0700 (PDT) MIME-Version: 1.0 References: <3688f589-d467-2144-0fae-6229266af109@gmail.com> <58cd1684-518c-aae1-e95c-b127651d4031@gmail.com> In-Reply-To: <58cd1684-518c-aae1-e95c-b127651d4031@gmail.com> From: Roman Shpount Date: Mon, 6 Jul 2020 19:14:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d73e2505a9ce0b5d" 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: Mon, 06 Jul 2020 23:15:14 -0000 --000000000000d73e2505a9ce0b5d Content-Type: text/plain; charset="UTF-8" I am arguing that the solution described is inadequate but it is not necessary to fix it, since the actual problem (overloading proxies or clients via session refresh) does not exist. _____________ Roman Shpount On Thu, Jul 2, 2020 at 9:41 PM OKUMURA Shinji wrote: > Roman, > > This problem was originally listed in RFC4028. I am proposing an amendment > because I believe the solution described in the RFC is inadequate. > Are you thinking that my claim that the RFC-listed solution is inadequate > is wrong? Or are you arguing that it's inadequate but not necessary to fix > it? > > Regards, > Shinji > > On 2020/07/03 2:19, Roman Shpount wrote: > > > > I am going to ask, once again, is this a problem which affects anybody? > > > > I would still argue that this is not a real security problem and should > be left as is. > --000000000000d73e2505a9ce0b5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am arguing that the solution=C2=A0described is=C2=A0inadequate but it is not necessary to fix it, = since the actual problem (overloading proxies or clients via session refres= h) does not exist.
_____________
Roman S= hpount


On Thu, Jul 2, 2020 at 9:41 PM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:<= br>
Roman,

This problem was originally listed in RFC4028. I am proposing an amendment = because I believe the solution described in the RFC is inadequate.
Are you thinking that my claim that the RFC-listed solution is inadequate i= s wrong? Or are you arguing that it's inadequate but not necessary to f= ix it?

Regards,
Shinji

On 2020/07/03 2:19, Roman Shpount wrote:
>
> I am going to ask, once again, is this a problem which affects anybody= ?
>
> I would still argue that this is not a real security problem and shoul= d be left as is.
--000000000000d73e2505a9ce0b5d-- From nobody Thu Jul 9 06:09: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 3AB393A09AC for ; Thu, 9 Jul 2020 06:09:49 -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 oHL4ZK9setjP for ; Thu, 9 Jul 2020 06:09:48 -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 4484E3A097F for ; Thu, 9 Jul 2020 06:09:48 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id f16so1094894pjt.0 for ; Thu, 09 Jul 2020 06:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=T4dxsg7vAT4rDBlSP4t+k0FO3R0h06eTQLRfJJPy6bs=; b=msIvH46d5xUYXn6ADHgRvSiubD9PDlGj2FoX5faWDk2AJEMgi2s1YRZ/ZwOaU94HLs nstjCufmq8ZrabDYgRfndt0hTMniAu01PomUyd/flmUX4cKYDAhl4J8MaT8PP4pm15zj rozSDKlNOhE5IcvtjM3djNbf4w0Jr9I8dL7/sIFmm4qLICxXmimjGGh69iFK2AdTTj2B VHvoruTz601Y3RsVsUbYfXxXO7ulb+4bExrPkcPJKd4veQqjMHtTE0Yp0lklKt1PzfZg Rqm+VReTvmGaA+p8/AfephGOe4cWur3PFb0LJcV06urUSm0vOMyhFAcDjNrY0V25NU4+ qqtg== 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:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=T4dxsg7vAT4rDBlSP4t+k0FO3R0h06eTQLRfJJPy6bs=; b=Cw5t8rWu0+/DpiPJpFb/1VYI6Oa0i4Do2RGxDk59Zpa84rg5LkAV3hLfTKmYWFYx9B yCPqOxcYbrl+ui8qbWP1SncorfCcZB+B/9bxkwc8dTXbouJdCTzFkc2IZbQx8S6jkhoT /Y3XnOphC22PZ8OvpfIaTTF3QS7Ge3PjEhAciCMiSGiAR2fc7OaDU2u6FjELi3ZIayh6 8FoUlcRqJLfDkppN3F8F5TyopH9wfOkRU+YKanr75YWmnhi6QXGROX6m+m6FvCXeCnJk skEFNLV6JB9Ou/JBzk2w5kEvYE2Kp9LWi4ReVPhFjH6eMPFrjiWp7sp/BhJzwd1sZcjb gs+Q== X-Gm-Message-State: AOAM5300wlgHoiPRq+8hdEdrgdKggG7ASAlfDHWR0iocV9+OkyZKxCwQ 2FgCLjXYy/bPCL+ltp8jX6hAa3B4 X-Google-Smtp-Source: ABdhPJzOgLdsW3c8sExl7WZUbE8GCtSEMhZ2PlWuvptjAgQQ0edn4dMFeO1PP9HNzLJdN4Qd9KzFbg== X-Received: by 2002:a17:90a:324c:: with SMTP id k70mr15718517pjb.18.1594300187134; Thu, 09 Jul 2020 06:09:47 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.111.er.eaccess.ne.jp. [112.136.68.111]) by smtp.gmail.com with ESMTPSA id t184sm2982326pfd.49.2020.07.09.06.09.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 06:09:46 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Message-ID: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> Date: Thu, 9 Jul 2020 22:09:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 200708-8, 2020/07/09), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 13:09:49 -0000 Hi, This is very basic question. Why must a proxy not increase SE-value? 1. UA sends INVITE(SE:100) 2. proxy rejects INVITE with 422(MSE:200) 3. UA sends INVITE again.(SE:200) 4. proxy forwards INVITE(SE:200) +-----+ +-------+ +-----+ | UA1 | | Proxy | | UA2 | +-----+ +-------+ +-----+ | | | | INVITE(SE:100) | | |------------------->| | | | | | 422(MSE:200) | | |<-------------------| | | | | | INVITE(SE:200) | | |------------------->| | | | | | | INVITE(SE:200) | | |------------------>| If proxy may increase SE-value, 1. UA sends INVITE(SE:100) 2. proxy forwards INVITE(SE:200) +-----+ +-------+ +-----+ | UA1 | | Proxy | | UA2 | +-----+ +-------+ +-----+ | | | | INVITE(SE:100) | | |------------------->| | | | | | | INVITE(SE:200) | | |------------------>| | | | Needless to say, this sequence is much simpler. Regards, Shinji From nobody Thu Jul 9 06:17: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 54B503A09E9 for ; Thu, 9 Jul 2020 06:17:21 -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 6K9w6hC4tcJM for ; Thu, 9 Jul 2020 06:17:19 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 BE7103A09E0 for ; Thu, 9 Jul 2020 06:17:19 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id g37so1643301otb.9 for ; Thu, 09 Jul 2020 06:17: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=3cW7ieuXxdVENXmT5Jfs1mtC1E6OxVOKQl3XSjr+vqg=; b=XiagLZPyDxDGM4eTCBX/JE67t8HCcoVSGMLR3YJyw+Ejb8OJSz136hrXDV/rYUGU4Z 2L3drGirShnAocRhttW3BvS1nLJyIkljYKVH5GFw7F/yA6SUppyMWtDuu2BF85BRtykj 0dYFc2GtK9zJ0DxgT0gUQdMCLU6Fs1z9qVmkFWppsEnJbOkpoRVqsdRD0cJTd42f/2Zc DHKZFNTsXV1cgoqFRryI/OqW0RPQRRVdinYl+IrhSUZsWNhUDxWxgIOvbAOgXPg5BMzO BoA899T+z24P2ZYBW7NnAEVF5VCon5J/uNgJoaZjT6mUWntBPd+5oNaiVufm5v0/9IlX ArPQ== 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=3cW7ieuXxdVENXmT5Jfs1mtC1E6OxVOKQl3XSjr+vqg=; b=rqv9Tx2+IKKnhdoohA6wlsWyabvKCchzhcYxIvWYFofHxxY/4al+rfiffv6uPCvsEn fGGKS5pGtTrCfciJhNIBD/zXDeZ6V34gIRC7toqxT+tqC8/Qd1A48jASu/sCK43LJHnn uMrm2vI5hx0JTLg2y0JGCl8jNGQgVoH8tgVx7lgGrrZfSADJ79N8OxPRkhJQboSybAiM cgKdG47R440b8RMBgJnj3ncpWUqAPtV58HjJEO82LSzKZcES7j8gPuJv5x5pei5f32Gh qaEjxZxwyCGOAxBB1SUksZwGj7NL0jUf5vMq0FRWYxjxpvAlouEcv2itBiTOAX6PaJ2I AOkQ== X-Gm-Message-State: AOAM531gRSGwA6c4uAGG+Kn7vfaCmGr+cPMx5fQUAw68m0ZbvLOzkSjx oWDKh2Mdjm2XpvHP/6o9adFCQ/mhMYo= X-Google-Smtp-Source: ABdhPJwHNwBszAMGBzXp4tJOqcF3NwN71YksAitKfjN1R9VZ4LA8DTpnvjQWIicpXcI9TcnhYXdFLQ== X-Received: by 2002:a9d:24e6:: with SMTP id z93mr53396292ota.360.1594300638258; Thu, 09 Jul 2020 06:17:18 -0700 (PDT) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com. [209.85.167.173]) by smtp.gmail.com with ESMTPSA id x5sm510161oic.21.2020.07.09.06.17.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 06:17:17 -0700 (PDT) Received: by mail-oi1-f173.google.com with SMTP id k22so1863903oib.0 for ; Thu, 09 Jul 2020 06:17:17 -0700 (PDT) X-Received: by 2002:a54:4e1d:: with SMTP id a29mr11494333oiy.139.1594300636981; Thu, 09 Jul 2020 06:17:16 -0700 (PDT) MIME-Version: 1.0 References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> In-Reply-To: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> From: Roman Shpount Date: Thu, 9 Jul 2020 09:17:04 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000021ee9e05aa020b6f" Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 13:17:21 -0000 --00000000000021ee9e05aa020b6f Content-Type: text/plain; charset="UTF-8" Shinji, This is a negotiation where all parties (UAC, UAS and proxies on path) must agree on the session timer value. Min-SE is the minimum allowed value. SE is the maximum allowed value. If Proxy needs a higher SE interval, it needs to renegotiate maximum allowed session timer value with all the parties upstream. This is why it rejects the request with 422 and a higher Min-SE value. BTW, there is no guarantee that session timer negotiation will succeed. In general case it is possible that session timer requirements for all the proxies UAC and UAS cannot be satisfied at the same time. Once again, may I ask, what is your motivation for proposing this change? Are you seeing an issue with a deployment somewhere? _____________ Roman Shpount On Thu, Jul 9, 2020 at 9:10 AM OKUMURA Shinji wrote: > Hi, > > This is very basic question. > > Why must a proxy not increase SE-value? > > 1. UA sends INVITE(SE:100) > 2. proxy rejects INVITE with 422(MSE:200) > 3. UA sends INVITE again.(SE:200) > 4. proxy forwards INVITE(SE:200) > > +-----+ +-------+ +-----+ > | UA1 | | Proxy | | UA2 | > +-----+ +-------+ +-----+ > | | | > | INVITE(SE:100) | | > |------------------->| | > | | | > | 422(MSE:200) | | > |<-------------------| | > | | | > | INVITE(SE:200) | | > |------------------->| | > | | | > | | INVITE(SE:200) | > | |------------------>| > > If proxy may increase SE-value, > 1. UA sends INVITE(SE:100) > 2. proxy forwards INVITE(SE:200) > > +-----+ +-------+ +-----+ > | UA1 | | Proxy | | UA2 | > +-----+ +-------+ +-----+ > | | | > | INVITE(SE:100) | | > |------------------->| | > | | | > | | INVITE(SE:200) | > | |------------------>| > | | | > > Needless to say, this sequence is much simpler. > > Regards, > Shinji > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000021ee9e05aa020b6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+U2hpbmppLDxkaXY+PGJyPjwvZGl2PjxkaXY+VGhpcyBpcyBhIG5lZ290 aWF0aW9uIHdoZXJlIGFsbCBwYXJ0aWVzIChVQUMsIFVBUyBhbmQgcHJveGllcyBvbiBwYXRoKSBt dXN0IGFncmVlIG9uIHRoZSBzZXNzaW9uIHRpbWVyIHZhbHVlLiBNaW4tU0UgaXMgdGhlIG1pbmlt dW0gYWxsb3dlZCB2YWx1ZS4gU0UgaXMgdGhlIG1heGltdW0gYWxsb3dlZCB2YWx1ZS4gSWYgUHJv eHkgbmVlZHMgYSBoaWdoZXIgU0UgaW50ZXJ2YWwsIGl0IG5lZWRzIHRvIHJlbmVnb3RpYXRlIG1h eGltdW3CoGFsbG93ZWQgc2Vzc2lvbiB0aW1lciB2YWx1ZSB3aXRoIGFsbCB0aGUgcGFydGllcyB1 cHN0cmVhbS4gVGhpcyBpcyB3aHkgaXQgcmVqZWN0cyB0aGUgcmVxdWVzdCB3aXRoIDQyMiBhbmQg YSBoaWdoZXIgTWluLVNFIHZhbHVlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QlRXLCB0aGVy ZSBpcyBubyBndWFyYW50ZWXCoHRoYXQgc2Vzc2lvbiB0aW1lciBuZWdvdGlhdGlvbiB3aWxsIHN1 Y2NlZWQuIEluIGdlbmVyYWwgY2FzZSBpdCBpcyBwb3NzaWJsZSB0aGF0IHNlc3Npb24gdGltZXIg cmVxdWlyZW1lbnRzIGZvciBhbGwgdGhlIHByb3hpZXMgVUFDIGFuZCBVQVMgY2Fubm90IGJlIHNh dGlzZmllZCBhdCB0aGUgc2FtZSB0aW1lLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T25jZSBh Z2FpbiwgbWF5IEkgYXNrLCB3aGF0IGlzIHlvdXIgbW90aXZhdGlvbiBmb3IgcHJvcG9zaW5nIHRo aXMgY2hhbmdlPyBBcmUgeW91IHNlZWluZyBhbiBpc3N1ZSB3aXRoIGEgZGVwbG95bWVudCBzb21l d2hlcmU/PGJyIGNsZWFyPSJhbGwiPjxkaXY+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX3Np Z25hdHVyZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+X19fX19fX19fX19fXzxi cj5Sb21hbiBTaHBvdW50PC9kaXY+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pjxicj48ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwg SnVsIDksIDIwMjAgYXQgOToxMCBBTSBPS1VNVVJBIFNoaW5qaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlldGYuc2hpbmppQGdtYWlsLmNvbSI+aWV0Zi5zaGluamlAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij5IaSw8YnI+DQo8YnI+DQpUaGlzIGlzIHZlcnkgYmFzaWMgcXVl c3Rpb24uPGJyPg0KPGJyPg0KV2h5IG11c3QgYSBwcm94eSBub3QgaW5jcmVhc2UgU0UtdmFsdWU/ PGJyPg0KPGJyPg0KMS4gVUEgc2VuZHMgSU5WSVRFKFNFOjEwMCk8YnI+DQoyLiBwcm94eSByZWpl Y3RzIElOVklURSB3aXRoIDQyMihNU0U6MjAwKTxicj4NCjMuIFVBIHNlbmRzIElOVklURSBhZ2Fp bi4oU0U6MjAwKTxicj4NCjQuIHByb3h5IGZvcndhcmRzIElOVklURShTRToyMDApPGJyPg0KPGJy Pg0KKy0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0rwqAgwqAgwqAgwqAgwqAgwqAg Ky0tLS0tKzxicj4NCnwgVUExIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgUHJveHkgfMKgIMKgIMKg IMKgIMKgIMKgIHwgVUEyIHw8YnI+DQorLS0tLS0rwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0t LSvCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0rPGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8 IElOVklURShTRToxMDApwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJy Pg0KwqAgwqAgfC0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgNDIyKE1TRToy MDApIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS18wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHw8YnI+DQrCoCDCoCB8IElOVklURShTRToyMDApwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfC0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgSU5WSVRFKFNFOjIwMCnCoCDCoCB8PGJyPg0K wqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwtLS0tLS0tLS0tLS0tLS0tLS0m Z3Q7fDxicj4NCjxicj4NCklmIHByb3h5IG1heSBpbmNyZWFzZSBTRS12YWx1ZSw8YnI+DQoxLiBV QSBzZW5kcyBJTlZJVEUoU0U6MTAwKTxicj4NCjIuIHByb3h5IGZvcndhcmRzIElOVklURShTRToy MDApPGJyPg0KPGJyPg0KKy0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0rwqAgwqAg wqAgwqAgwqAgwqAgKy0tLS0tKzxicj4NCnwgVUExIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgUHJv eHkgfMKgIMKgIMKgIMKgIMKgIMKgIHwgVUEyIHw8YnI+DQorLS0tLS0rwqAgwqAgwqAgwqAgwqAg wqAgwqArLS0tLS0tLSvCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0rPGJyPg0KwqAgwqAgfMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCB8IElOVklURShTRToxMDApwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB8PGJyPg0KwqAgwqAgfC0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgSU5WSVRFKFNFOjIwMCnCoCDCoCB8PGJyPg0KwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwtLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxi cj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8PGJyPg0KPGJyPg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNlcXVlbmNl IGlzIG11Y2ggc2ltcGxlci48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClNoaW5qaTxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K c2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmU8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPjwvZGl2Pg0K --00000000000021ee9e05aa020b6f-- From nobody Thu Jul 9 07:42:32 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 6865F3A0BFD for ; Thu, 9 Jul 2020 07:42:30 -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 B8xeIBdn-51Q for ; Thu, 9 Jul 2020 07:42:28 -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 90A223A0BE9 for ; Thu, 9 Jul 2020 07:42:28 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id t11so1097308pfq.11 for ; Thu, 09 Jul 2020 07:42: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=1glKFgqrHaU4ZjBd2nyqRJWfvf/ikQCjIufrWqEDM9Q=; b=OprpTN0jAe4NPzkERu4D/YXcB0KJfFC4BX4absypllNTh6v7weaE1CmIBDRRv0Lr2J wx3+KnYmAEzxTx0z1HJDfdFxPEOrAuFGWH3HMMWFSd7n3bK/offYBreKX5aN/7NM8BrA iLuoAm/rRgQ2OIPsEqXJI6DbxXPCUU9sYW4w1LWxSxvsI7UfBjqeliL3XfBrH78RF7rv 7ufR2z4kLiLq4nioOWPguFmtFKEBE2TLtmN2XJLiw72yfIDaxf+tFWqXT07BOVMhmlOe Jbm8y6WDAeupAN8DQgbF93MO51Vxi3zCqCr+DyCzIJH1OIx11ctaytQ97qjDYh2ob+JV OgOg== 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=1glKFgqrHaU4ZjBd2nyqRJWfvf/ikQCjIufrWqEDM9Q=; b=AIQbAYNfNmYkpWZMg+5OXd1/mzlgzeu+qdSsXnD5vejZIuzL0q6HalceWnY7SdnPW0 0Ja5pReoQ3rgOIiwpzeiMcbHGU6qI6qH0xlSa68/pM/7iCwpqUPdLQ7Fmh2onYizO1q6 69CwAgVEsNEEPMTvRleaarzI0q5VQ3tXdDWppOtybkos78B9ztXaPn7swc4aQi/7ZkQ/ sMuj00O1O+wSchuVaMNd9Sl1voIhNYyDr947LBC/MmPitDNURD10kRwIChudpN4SE+D5 vGb9ee1q9Vo9x8ESgval7bbNnX4IeEgOTMLq2lYFnNgZJkJkjx0N1/mMIYt7NHQvQ6sg QgJg== X-Gm-Message-State: AOAM531RL3qU2nkPjczYwuV9VSjSEM0y/iEO7XfLp6M+wXIZyiJ9BX4U +AXBRCBk4fCvXe60ltnnzrel+ac1 X-Google-Smtp-Source: ABdhPJw1HY2iVOZfhk1Ye6BXb2KLkZNXmuub3signw0KU/Uz7z0lb0c+fwsGhQ4KsoqfDJGi1uRXCQ== X-Received: by 2002:a62:16:: with SMTP id 22mr41854369pfa.120.1594305747860; Thu, 09 Jul 2020 07:42:27 -0700 (PDT) Received: from [192.168.128.64] (112.136.68.111.er.eaccess.ne.jp. [112.136.68.111]) by smtp.gmail.com with ESMTPSA id c71sm3334176pje.32.2020.07.09.07.42.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 07:42:27 -0700 (PDT) To: SIPCORE Cc: Roman Shpount References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> From: OKUMURA Shinji Message-ID: <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> Date: Thu, 9 Jul 2020 23:42:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 200708-8, 2020/07/09), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 14:42:31 -0000 Roman, I haven't proposed a fix for this YET. This is a pure question at this point in time. > SE is the maximum allowed value. UAC can send again with a greater Session-Expires and Min-SE. The proxy CAN NOT reject the INVITE just because "Session Interval Too Large". Therefore SE isn't the maximum allowed value. > If Proxy needs a higher SE interval, it needs to renegotiate maximum allowed session timer value with all the parties upstream. If Proxy needs a higher SE interval, the proxy need only increase SE-value. This procedure definitely works. Because this is the very procedure for when the UAC does not support timer. Again, proxies can't reject the INVITE just because the timer is too large. > Once again, may I ask, what is your motivation for proposing this change? My motivation is that bis become to be more clear and error-free. > Are you seeing an issue with a deployment somewhere? No, You seem to attach great importance to that point, but I don't understand the importance of that. Do you argue that it is enough for each developer to address any issues on their own? Regards, Shinji On 2020/07/09 22:17, Roman Shpount wrote: > Shinji, > > This is a negotiation where all parties (UAC, UAS and proxies on path) must > agree on the session timer value. Min-SE is the minimum allowed value. SE > is the maximum allowed value. If Proxy needs a higher SE interval, it needs > to renegotiate maximum allowed session timer value with all the parties > upstream. This is why it rejects the request with 422 and a higher Min-SE > value. > > BTW, there is no guarantee that session timer negotiation will succeed. In > general case it is possible that session timer requirements for all the > proxies UAC and UAS cannot be satisfied at the same time. > > Once again, may I ask, what is your motivation for proposing this change? > Are you seeing an issue with a deployment somewhere? > _____________ > Roman Shpount > > > On Thu, Jul 9, 2020 at 9:10 AM OKUMURA Shinji wrote: > >> Hi, >> >> This is very basic question. >> >> Why must a proxy not increase SE-value? >> >> 1. UA sends INVITE(SE:100) >> 2. proxy rejects INVITE with 422(MSE:200) >> 3. UA sends INVITE again.(SE:200) >> 4. proxy forwards INVITE(SE:200) >> >> +-----+ +-------+ +-----+ >> | UA1 | | Proxy | | UA2 | >> +-----+ +-------+ +-----+ >> | | | >> | INVITE(SE:100) | | >> |------------------->| | >> | | | >> | 422(MSE:200) | | >> |<-------------------| | >> | | | >> | INVITE(SE:200) | | >> |------------------->| | >> | | | >> | | INVITE(SE:200) | >> | |------------------>| >> >> If proxy may increase SE-value, >> 1. UA sends INVITE(SE:100) >> 2. proxy forwards INVITE(SE:200) >> >> +-----+ +-------+ +-----+ >> | UA1 | | Proxy | | UA2 | >> +-----+ +-------+ +-----+ >> | | | >> | INVITE(SE:100) | | >> |------------------->| | >> | | | >> | | INVITE(SE:200) | >> | |------------------>| >> | | | >> >> Needless to say, this sequence is much simpler. >> >> Regards, >> Shinji >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From nobody Thu Jul 9 08:16: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 AC6BF3A0CC0 for ; Thu, 9 Jul 2020 08:16:14 -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 jvP6rxjIOJM4 for ; Thu, 9 Jul 2020 08:16:13 -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 E52B03A0CAE for ; Thu, 9 Jul 2020 08:16:12 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 5so1915824oty.11 for ; Thu, 09 Jul 2020 08:16: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=KXj0higAZ8d1QylpRQnOQVii+tZ0rCOOpne0FFLyxHI=; b=VdBKQD13fJDg7QAjFljuCSp1euyrnwxVoY9dkBOy8/nTXpK2deRtp+tmWISZBjcGaa qgxMXU7Zcuh2WTw8SITtWHuyU3E4CXKvIb0cALOva8n0+bIb9mlYLeAqgNSnfK81fJLa j4hV8MUvBHGXW2B0GI1VntwQ+tunCf8VpXVca6z5AFsrZoKnbTukMEc0Eh29oNy5aBRW hVvfvZ2RJy1n2bj5fqMHGpjvM2oxTDWO/dJz8fsHkDX4DYFhwbXyHEfpqWLxetHuuQo3 BEQdnVS61KzGIHsfWVvggWX3KajfZuDmcI4zafzQL1ehz5Ct1k4ksA8v0YUneZeI44bk Qg7g== 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=KXj0higAZ8d1QylpRQnOQVii+tZ0rCOOpne0FFLyxHI=; b=PRYG2GfK5fSChttTTQXTjI5Hf3LfaHL5AstUPRQ96S69yaxFGhC2rnduhtxwcAtqi2 xZhcFb6/LZwSwGMlOEXR0h3qJmp1PDpwvzl07hBmQRS4sj3UZ/BO7fxFk0orxWGDqeCl C8bDOBH0Sdoc3M7mMcKX5TZLmboBLkGywB/NX+me6nY1cMxkR8Z24/tOxriO7V5dD1vw /ooVVcn/kngVZGknfiPG9dqHARRqdVBPS3tCjEzS7C6t6O3iECNdPQTYEY0QrP8b2k48 eey45199mrNVqhqNLVTeNOdeIknbJqn8U7VHVcz7gEMVn82KT+Oe6nGFtkdj48KRNVAw rUHA== X-Gm-Message-State: AOAM531O9hywdaKl2I781AKZo+wP+U1sJisJ2VqByMcI8aQh1F1VXuS1 FMIz9yY444KjQyoJClTul3R/hwfefeM= X-Google-Smtp-Source: ABdhPJy+xkM3iD5O1iQDD6sXz09nxmlY9PLktv/i6N8Fgd0Hg+YMI7lln0WU0WhICIm04jeYqbwYSw== X-Received: by 2002:a9d:7f09:: with SMTP id j9mr38753361otq.111.1594307771422; Thu, 09 Jul 2020 08:16:11 -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 r22sm623423ooq.37.2020.07.09.08.16.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 08:16:10 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id 72so1946443otc.3 for ; Thu, 09 Jul 2020 08:16:10 -0700 (PDT) X-Received: by 2002:a05:6830:1db9:: with SMTP id z25mr26485890oti.13.1594307769766; Thu, 09 Jul 2020 08:16:09 -0700 (PDT) MIME-Version: 1.0 References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> In-Reply-To: <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> From: Roman Shpount Date: Thu, 9 Jul 2020 11:15:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: OKUMURA Shinji Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000004796c005aa03b417" Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 15:16:21 -0000 --0000000000004796c005aa03b417 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 9, 2020 at 10:42 AM OKUMURA Shinji wrote: > > SE is the maximum allowed value. > > UAC can send again with a greater Session-Expires and Min-SE. The proxy > CAN NOT reject the INVITE just because "Session Interval Too Large". > Therefore SE isn't the maximum allowed value Why do you think it cannot? Proxy can reject a new INVITE for any reason it sees fit. > .> If Proxy needs a higher SE interval, it needs to renegotiate maximum > allowed session timer value with all the parties upstream. > > If Proxy needs a higher SE interval, the proxy need only increase > SE-value. This procedure definitely works. Because this is the very > procedure for when the UAC does not support timer. > Again, proxies can't reject the INVITE just because the timer is too large. > The higher SE interval value might be too high for proxies upstream. Your procedure breaks it. Again, proxies can reject INVITE for any reason. > Once again, may I ask, what is your motivation for proposing this change? > > My motivation is that bis become to be more clear and error-free. > I have zero interest in this. Session Timer (and most of SIP related specifications) are effectively legacy specifications in maintenance mode. You need to show serious reasons to introduce major changes at this point. > Are you seeing an issue with a deployment somewhere? > > No, You seem to attach great importance to that point, but I don't > understand the importance of that. > Do you argue that it is enough for each developer to address any issues on > their own? > I am arguing that this is an old and widely deployed specification. It might not be clearly written but it is widely implemented which resulted in some general consensus on how it is supposed to work. Making changes to it is dangerous unless they are targeting specific issues. There is something to be said about redoing the entire SIP specification to be clearer and more logical, but this would be a different and much bigger effort. Also, I do not see that enough people have interest in doing and, what is much more important, implementing this new SIP specification. I understand your desire in cleaning up the Session Timer specification, but it would effectively render the resulting document irrelevant due to most people refusing to implement changes which are too great. Best Regards, _____________ Roman Shpount --0000000000004796c005aa03b417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 9, 2020 at 10:42 AM OKUMURA S= hinji <ietf.shinji@gmail.com> wrote:
> SE is the maximum allowed value.

UAC can send again with a greater Session-Expires and Min-SE. The proxy CAN= NOT reject the INVITE just because "Session Interval Too Large".= Therefore SE isn't the maximum allowed value

Why do you think it cannot? Proxy can reject a new INVITE for any re= ason it sees fit.
=C2=A0
.> If Proxy needs a higher SE interval, it needs to reneg= otiate maximum allowed session timer value with all the parties upstream.
If Proxy needs a higher SE interval, the proxy need only increase SE-value.= This procedure definitely works. Because this is the very procedure for wh= en the UAC does not support timer.
Again, proxies can't reject the INVITE just because the timer is too la= rge.
=C2=A0
The higher SE interval=C2=A0valu= e might be too high for proxies upstream. Your procedure breaks it. Again, = proxies can reject INVITE for any reason.

> Once again, may I ask, what is yo= ur motivation for proposing this change?

My motivation is that bis become to be more clear and error-free.
=C2=A0
I have zero interest in this. Session Timer (a= nd most of SIP related specifications) are effectively legacy specification= s in maintenance mode. You need to show serious reasons to introduce major = changes at this point.

> Are you seeing an issue with a deployment somewhere?=

No, You seem to attach great importance to that point, but I don't unde= rstand the importance of that.
Do you argue that it is enough for each developer to address any issues on = their own?

I am arguing that this is an= old and widely deployed specification.=C2=A0 It might not be clearly writt= en but it is widely implemented which resulted in some general consensus on= how it is supposed to work. Making changes to it is dangerous unless they = are targeting specific issues.

There is something = to be said about redoing the entire SIP specification to be clearer and mor= e logical, but this would be a different and much bigger effort. Also, I do= not see that enough people have interest in doing and, what is much more i= mportant,=C2=A0implementing=20 this new SIP specification. I understand your desire in cleaning up the Ses= sion Timer specification, but it would effectively render the resulting doc= ument irrelevant due to most people refusing to implement changes which are= too great.

Best Regards,
_____________
Roman Shpoun= t=C2=A0
--0000000000004796c005aa03b417-- From nobody Thu Jul 9 08:36: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 0BB773A0CDC for ; Thu, 9 Jul 2020 08:36:51 -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, 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 dNxzIluqfmo6 for ; Thu, 9 Jul 2020 08:36:49 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::615]) (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 687A83A0CDA for ; Thu, 9 Jul 2020 08:36:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uqn//D4pEAcGekBfQKpumQUWg3SGQsumAjf5KVQOUcd/qHJF7jrShEziwalZAGmaf18ICS4f34trzVuUmkeKpGqvlvgN8h8PhUtWxRGFwZsDIqmNGX/PEmSetJ/tncINLyM1C6yk7UPw2LoUcdUj+V93pwy++sb+4Mdn0SsGARM09zz0PeDV1sDCMXAh1nKHwBh5BXad+aE7p2hbBt+D1OGKa3NldTQ1D/MwkRaE0036qwm2IpsiDBIdITs2Yro/BPkF2nhWTkFLMKE9DTTSddJESNLKQQu7mBDV/ZMYBDNexAmaAfQY8O8nbEbz5wj7oXu1NTUl7DIor3mqbRHhTw== 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=NVW9FCk7WpU0aLiLjme0BR0bseD680/fwtHUcslcO7k=; b=UTZlcfNNDW23kQlcacsPgMcr4gyVG/CIeMBlXL/hTjHUW4YWJRKjApqgP0vGFfmlvY8wChARE/vBVHhf/0PdlMrg9OTuCubCCwgU/PTikqNhyvOfBiPhT+pmIOxEjAy35sEdwHfbWuTUxoAx9ZXRZDukEm7blOpdilQpYQ2Ba1ZYMLIqGtmufB56Ly1MCbf4AWNL/BAqccB/L7nHR30zji+BHlLV7eVrdRYQ2GC1Pc+i5ZLDsXG14wRhXJBpupNB5GTHDg9zTsfDZh8rRqCVYwKnnQAcM6uF65pgrM/XlT/REYvsnO0qwDrC2LiQHh2/iGFXMTog86QjFcWLZ55oVg== 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=NVW9FCk7WpU0aLiLjme0BR0bseD680/fwtHUcslcO7k=; b=gDImYR3pdpTitTpOefm0Tk9rvTHkll3IijnSiLQWOimxXZPdfdupknw5WhSniLoYG8MTszSiWH2AbB0jeJsJ1CrG2ihdbsMswQ7rtU0KdshfXIKsxWoKKUps9mGv0F54UKJ4nb25PqAgx1Q5F7zShvUCNwOJ8k8z1a4vudk3o5g= Received: from SN1PR12CA0068.namprd12.prod.outlook.com (2603:10b6:802:20::39) by BN6PR12MB1843.namprd12.prod.outlook.com (2603:10b6:404:101::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Thu, 9 Jul 2020 15:36:48 +0000 Received: from SN1NAM02FT018.eop-nam02.prod.protection.outlook.com (2603:10b6:802:20:cafe::ca) by SN1PR12CA0068.outlook.office365.com (2603:10b6:802:20::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Thu, 9 Jul 2020 15:36:47 +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 SN1NAM02FT018.mail.protection.outlook.com (10.152.72.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Thu, 9 Jul 2020 15:36:46 +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 069FajpF002861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Jul 2020 11:36:45 -0400 To: sipcore@ietf.org References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> From: Paul Kyzivat Message-ID: <0f61d2bc-6af1-8e2b-c593-0c2862b90cd3@alum.mit.edu> Date: Thu, 9 Jul 2020 11:36:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.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)(39860400002)(136003)(376002)(396003)(46966005)(47076004)(186003)(6916009)(82740400003)(956004)(2616005)(36906005)(5660300002)(75432002)(336012)(83380400001)(26005)(478600001)(2906002)(53546011)(70586007)(70206006)(786003)(316002)(82310400002)(7596003)(356005)(8936002)(31696002)(86362001)(31686004)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d85b140-71fc-4035-64df-08d8241de413 X-MS-TrafficTypeDiagnostic: BN6PR12MB1843: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9zrg7hOZFxOu91Eee7xPdOeT1m7FTCo5Mshlxqyv65lcutr+G7jhH2lBI/7ZyQHnea5QvHLprrcfMfDV2EXbcsDNWegs5OuYJtDmqY48F/pAWVeVNBKFdBo3SXBs4zbQdF3c1t6KRS1SGdeBgiYDBsM/WyTuCqjNm0jLaXNTmgn2GuJoDrGwMjDcwD1HnptPjbuzk68zgwxj/ZABz/b78Hx6wcrzbetZI/R21zAd+reSfpFakdn8YMlaxqlwhOGt0J/wRkTwmmnaYkMxRnfQZHfEQcvAF25cc+hxRxCtzGo1rCsB7JCbNxcUGoPWuZAMKh0HrEYKU8EVOxof1c8AX+0PqJpEThTNs+JYco/+gLMvsk5uZxoq2iiB2K+/qJPe/m8oPz8GI+zrb8ZCRE0y1wLsCax9RxAsDv1w5DI3ZDOw+0ndwfTOXRxvlRqobLmK X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2020 15:36:46.9394 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8d85b140-71fc-4035-64df-08d8241de413 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: SN1NAM02FT018.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1843 Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 15:36:51 -0000 On 7/9/20 9:17 AM, Roman Shpount wrote: > Shinji, > > This is a negotiation where all parties (UAC, UAS and proxies on path) > must agree on the session timer value. Min-SE is the minimum allowed > value. SE is the maximum allowed value. If Proxy needs a higher SE > interval, it needs to renegotiate maximum allowed session timer value > with all the parties upstream. This is why it rejects the request with > 422 and a higher Min-SE value. What is the point of session timer? It is to use traffic on the session to verify liveness of the session and of the parties on the path. This pertains to both UAs and proxies, but their needs differ in some respects: 1) proxies can't initiate traffic; they must depend on observing traffic generated by the UAs. So they have an interest in requesting that the UAs send traffic with some minimum frequency. 2) UAs can test liveness any time they want by sending a request, without need of session timers. But if both ends do this independently then there may be more traffic than necessary, and possibly glare. ST negotiations allow them to find a mutually agreeable keep-alive interval and refresher, minimizing overhead. The negotiation process allows all the parties to express an opinion. It works by ratcheting up the minimum value and ratcheting down the maximum value to find a mutually agreeable value between. No party is allowed to increase the max or decrease the min. The purpose of Min-SE is to limit the overhead caused by ST refreshes when there otherwise would be no traffic. (Aside from this there would be no need for Min-SE.) The benefit of ST falls mostly to the proxies, while the cost is typically heavier on the UAs. So the Min-SE is primarily for the purpose of protecting the UAs from excessive demands by proxies. > BTW, there is no guarantee that session timer negotiation will succeed. > In general case it is possible that session timer requirements for all > the proxies UAC and UAS cannot be satisfied at the same time. Yes. If, at the end of the negotiation, Min-SE and SE are higher than one of the UAs desires, it is still free to send extra traffic to test liveness more often than the ST refreshes do. If the Min-SE and SE are higher than one of the proxies desires, then it is pretty much out of luck. In some sense this is futile for it to complain because the timer refreshes are only part of the traffic. The UAs may send other traffic at a rate the proxy doesn't like, and there is little it can do about that. It can try the 422 route, but only if it would prefer no session over a session with more traffic. Thanks, Paul From nobody Thu Jul 9 08:48: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 BE8203A0C93 for ; Thu, 9 Jul 2020 08:48:23 -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 D7EhJ7SvRQ5d for ; Thu, 9 Jul 2020 08:48:21 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2080.outbound.protection.outlook.com [40.107.220.80]) (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 9A5E03A0C88 for ; Thu, 9 Jul 2020 08:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CYh/rfYQkJRNd+iZpWmH31jCYPFRHHrTFhwNDXRyYt7Z3K3FSsLkx1743J411YRm+qggnJPedJINOixGodo46ikqJXZduoAKVoSHzkrYNutmObNPrSV6P8+SIqOJXV1wSSULf7aQUC41OIaww6kntbqOKCjBGn5P2CsWh8Ob/XXC5V47TyNhM63TQXaCAvmLDP7Dro0M/di38ZoRXN+OO63l8TPwVZX7XHcrK8eLjUm201cotF7t0L4+7lD3pRT/b3WnkiGi+lbEe3+HGPcQVE9kgYLzOZVcnfaN50fW+LIZUMjjPCYozXXRvfK/8NvqXoGxk4N6Q+2NOnHfBr1Oeg== 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=oAlTr8HUHE4B9vc8OtgWhWoyRLQPjN6pFDzgJgg8Y2I=; b=W5KiruqtnXT2G+Skd6h8q7Mi9JgCZ26d3AUHWFHoWRzNGP0pEVqJ8T5etZMb3fgvEuZDrrWAeKWTpHicDXy7jT0ajK1pngb9oZGZnzk24xG2xi0aRcSAv+xoWex6C2QFTBSZSWu6IgJoP1/ZhZXprywsKvLmW9VjsD3kM99YO/ggCFxrexJf0/w9YiwfxgxmZ7byVvXDtN9yj/zA4t1qjwp2mDkcN/TsN2KaGC1aWiyWzpMVDnvU0MHS1um6A82L6hsildB62iusCWNaCSy9CffXXNri4RfO2cRJGXmrqQULgXnBvS2kER7ztZt8UHJHa3ZHF9lPJtXJyGUasxpm3g== 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=oAlTr8HUHE4B9vc8OtgWhWoyRLQPjN6pFDzgJgg8Y2I=; b=FbiUbkH0xfCcjapr2CuJy0DSL1WFjrt4n4fbm8nrNqV2trxkQgt8CF4KOcf+wTdE9UkH238yDETDAmS9R11kg8zwJkDdEgPbejvUaVU3pWqoXe/odB3H2fJ6T3K1X4P3Az27sHv3LopsKuvzDnHOFI8kI3kkL9avscdUnOjA0wY= Received: from CY4PR20CA0009.namprd20.prod.outlook.com (2603:10b6:903:98::19) by MW2PR12MB2492.namprd12.prod.outlook.com (2603:10b6:907:8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Thu, 9 Jul 2020 15:48:19 +0000 Received: from CY1NAM02FT021.eop-nam02.prod.protection.outlook.com (2603:10b6:903:98:cafe::8e) by CY4PR20CA0009.outlook.office365.com (2603:10b6:903:98::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22 via Frontend Transport; Thu, 9 Jul 2020 15:48:19 +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 CY1NAM02FT021.mail.protection.outlook.com (10.152.75.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Thu, 9 Jul 2020 15:48:18 +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 069FmGJe003744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Jul 2020 11:48:17 -0400 To: sipcore@ietf.org References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> From: Paul Kyzivat Message-ID: <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> Date: Thu, 9 Jul 2020 11:48:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.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)(136003)(396003)(346002)(46966005)(75432002)(36906005)(47076004)(786003)(82740400003)(316002)(53546011)(5660300002)(8676002)(186003)(478600001)(26005)(70206006)(31686004)(70586007)(7596003)(8936002)(6916009)(82310400002)(356005)(2906002)(86362001)(4744005)(956004)(2616005)(31696002)(336012)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 363fd7a2-651e-46ca-2795-08d8241f8066 X-MS-TrafficTypeDiagnostic: MW2PR12MB2492: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 04599F3534 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LfdfySSvsptPAbmkIGg9eSB6Ql2smJ9BCXDFF8wWgSZbQwA4UQ1S8ZWwQ7YMfzxLsTtKQ1syyysQHz7tq2fLcNBKsEQakx7s6W3YB9asj8zSuYsVY7yC0frpOe/XcI5NqMaDKqY8Gni+/KbKcMlzcloZlGFroZaWigCshkRfuDAp8ymvIKKf7Vx5270THEdv6EXDfpymHRQuTlrZVAwmYnuf53p9QtipnCKc/ftySrdEUmSQHDBfoYHVc7g8UnWKBVxnUe9ibLF2PxMYc0eD/3WCD9MvZOx36evlXT/7rpW0UUq4zvbjG77IVnPJsTHxxoNsQ1cVwUZich2qqq6qgPUhpKNrNxpon9jDju6oNhvhtuJSm4IeLp2+mwhHAXKzY/ixozzvz+sgvUM40ZRvotRRDA2F6Paw+fQKu0g7AYY= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2020 15:48:18.6541 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 363fd7a2-651e-46ca-2795-08d8241f8066 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: CY1NAM02FT021.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR12MB2492 Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 15:48:24 -0000 On 7/9/20 11:15 AM, Roman Shpount wrote: > No, You seem to attach great importance to that point, but I don't > understand the importance of that. > Do you argue that it is enough for each developer to address any > issues on their own? > > I am arguing that this is an old and widely deployed specification.  It > might not be clearly written but it is widely implemented which resulted > in some general consensus on how it is supposed to work. Making changes > to it is dangerous unless they are targeting specific issues. I have been fielding questions about this rfc for almost two decades. Based on that there is widespread misunderstanding of it. I think it would be very helpful to at least add some overview discussion of what this mechanism is good for and what it is not good for. Something along the lines of what I put in my prior reply. Thanks, Paul From nobody Thu Jul 9 09: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 A12063A0CDB for ; Thu, 9 Jul 2020 09:15:23 -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 etnDW_XEnAAj for ; Thu, 9 Jul 2020 09:15:21 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 CFDCB3A0CD8 for ; Thu, 9 Jul 2020 09:15:21 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id 5so2058167oty.11 for ; Thu, 09 Jul 2020 09:15:21 -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=cbCI/gh3ejukaTH7orsfaKnnu3T4Js8AxcDf+6YcVjU=; b=Thtt+xM/ZMGDzh94folIdT7bPfwg1chy3ypA52Yj4kR9OnH/H7YSagWajeXebutNGc amSXwkMnlsUn6mCha+lf7dUUtQcRhy0pLRkpj9BmWr/CD8KXXm8gcq3uBfQNqcjw3eRA JZWRrbgG92CtwfpwrofCp1SovtNS7Lk8VdOqIudJpqAsn8xxXmw/+NZNRiASOf+W9aII PxVdrbelr82Evra9PtBQJgdVigPeopHq+1PeLmMkevLXI8x9w5zIcbY8OUS4Tn3TLs2L ToRQ5Ud0Mo+ioSkMDn1hWZ3VmXjJ4CPrD6PzatiH8dHl6XoXZ+NYsy/e5HOAWMIa+y/+ vB1w== 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=cbCI/gh3ejukaTH7orsfaKnnu3T4Js8AxcDf+6YcVjU=; b=gGit6bVXawDKYF9CGC4wlOaITRec+0q7QVWnwcswlfGTwMnz7sExLMmjntmsRlspqh ICRyDut+owSPEQ8NRpomgklR305DTdRNai5fIPgf9C6C7bzPxM6KcmkSAK+tlAfktpUI 07SsPaE9oAWvfRj2sOcVOo/6T0dMd2Y5UUZ07q5u33L6hbTwhm/GGlTaOxMFOuYkCWy6 DJVSECEo4wGNeAhZQKG4tYf3/TaabC4ECSBuetXdQdaoLiI/VcMJZEmUQh5EkTIqpQOG 8ZY/4d2PBmn0AB9ENWH09dYopyU5K5bSgg7cZpcDRZjOGDR7082pEEoRT3AL+9JM9+lB h4cg== X-Gm-Message-State: AOAM530vE8pgI9J31t5BKfe5PlZp/2OhO7WyU1WoLxAIAtxQwHlczWLu /BT2xYXl8QIZ+U9kRVGQXJ5eWg1k+5Y= X-Google-Smtp-Source: ABdhPJxzjDfXfa2Y+8RoBVNA7myqZnp6N6kA+qgyCpGRrOOYZPh2W0XWXf+E+D9FkBi/N708T45MjA== X-Received: by 2002:a9d:222:: with SMTP id 31mr32075323otb.127.1594311320588; Thu, 09 Jul 2020 09:15:20 -0700 (PDT) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com. [209.85.167.178]) by smtp.gmail.com with ESMTPSA id s4sm658388oom.15.2020.07.09.09.15.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 09:15:19 -0700 (PDT) Received: by mail-oi1-f178.google.com with SMTP id j11so2290793oiw.12 for ; Thu, 09 Jul 2020 09:15:19 -0700 (PDT) X-Received: by 2002:aca:c690:: with SMTP id w138mr751519oif.12.1594311319360; Thu, 09 Jul 2020 09:15:19 -0700 (PDT) MIME-Version: 1.0 References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> In-Reply-To: <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> From: Roman Shpount Date: Thu, 9 Jul 2020 12:15:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000da16db05aa048737" Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 16:15:24 -0000 --000000000000da16db05aa048737 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 9, 2020 at 11:48 AM Paul Kyzivat wrote: > On 7/9/20 11:15 AM, Roman Shpount wrote: > > > No, You seem to attach great importance to that point, but I don't > > understand the importance of that. > > Do you argue that it is enough for each developer to address any > > issues on their own? > > > > I am arguing that this is an old and widely deployed specification. It > > might not be clearly written but it is widely implemented which resulted > > in some general consensus on how it is supposed to work. Making changes > > to it is dangerous unless they are targeting specific issues. > > I have been fielding questions about this rfc for almost two decades. > Based on that there is widespread misunderstanding of it. > > I think it would be very helpful to at least add some overview > discussion of what this mechanism is good for and what it is not good > for. Something along the lines of what I put in my prior reply. > I would definitely agree to that. An informational, non-normative section in the RFC overview can help a lot. What I am trying to avoid is ending up with a non-obvious set of changes to an existing specification which will act as a barrier to implementation. Letting proxies increase SE would be an example of such change. _____________ Roman Shpount --000000000000da16db05aa048737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 7/9/20 11:15 AM, Roman Shpount wrote:

>=C2=A0 =C2=A0 =C2=A0No, You seem to attach great importance to that poi= nt, but I don't
>=C2=A0 =C2=A0 =C2=A0understand the importance of that.
>=C2=A0 =C2=A0 =C2=A0Do you argue that it is enough for each developer t= o address any
>=C2=A0 =C2=A0 =C2=A0issues on their own?
>
> I am arguing that this is an old and widely deployed specification.=C2= =A0 It
> might not be clearly written but it is widely implemented which result= ed
> in some general consensus on how it is supposed to work. Making change= s
> to it is dangerous unless they are targeting specific issues.

I have been fielding questions about this rfc for almost two decades.
Based on that there is widespread misunderstanding of it.

I think it would be very helpful to at least add some overview
discussion of what this mechanism is good for and what it is not good
for. Something along the lines of what I put in my prior reply.

I would definitely agree to that. An informational= , non-normative section in the RFC overview can help a lot.

<= /div>
What I am trying to avoid is ending up with a non-obvious set of = changes to an existing specification which will act as a barrier to impleme= ntation. Letting proxies increase SE would be an example of such change.
_____________
<= /div>
Roman Shpount=C2=A0
--000000000000da16db05aa048737-- From nobody Thu Jul 9 10:11: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 28A433A0D09 for ; Thu, 9 Jul 2020 10:11:38 -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 yiVgFV5eeuaM for ; Thu, 9 Jul 2020 10:11:36 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2046.outbound.protection.outlook.com [40.107.243.46]) (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 B01C53A0D07 for ; Thu, 9 Jul 2020 10:11:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=McrIBJ2SEhuIcrBcsPzo5WTGk6sbG2LgUUN/6wDwk/ZyPfBLEDsB71vL1rLUlpCg+PrkJpTxZ8npIall/pBOnzv7LU/L8k+I0uBEgPmjtUrdKpO57KhiiyAroDrJTX3JOhRiolc6ALiUsz2wmKPBKQUDCUjCCPbkcQRfVlnqiYsSscM8d/VLHRLG4OE2Yy95DOata3alQejUnwyutzjS9JYpB0XbyjGfp7M2HCJFg5vCxUcbNQ4KElhOp6E4ySsOZJFOtbdjflycGOsV/mBiiKswN3oh97HG8wkj9U7Nd8CBvNoLsX8wLO6S43V5BPVEuW1l9jH6O959BSc7NuDVrg== 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=R0aqZmTFTe+VmsnYv3r29kCbcPFi/hcjWN3z4eEa2Fo=; b=X+HHK8FMPDCDYO1LyngYYRw2gZxv+SadR74pyS4pElPsX+CXZfby6v4ztO1c+2hV19iSz5uH2BwkpA6F649DXlcLMXCVSXNB8AYFHX1/yR8TSKWq1jCc5gbcpUNv3LsthwiUpj2nbtoJJnW+3XYM+GEGheg+nvVrvkvcpH8dd9FIX1eMR5RyMOVKGjd9bTKVB9g1kesuKL4V8UUIe3B19WFwlQhuZ2XGY1J0gx+BcFn6gGlm9Cdjw7KExmvRifpYwtXcbLq5rcI97eZA+AzhP0jfkQ5pI/vX2ESa2oAKpfKEgbKazIsLPSLuL+FTJQhsrZOBkpEKysSdZ8YkkkDuXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=telurix.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=R0aqZmTFTe+VmsnYv3r29kCbcPFi/hcjWN3z4eEa2Fo=; b=eRO/wBvCzP6w9bbx62muZFH9feYpNfTWWQKmL92R7lWG6ty4Q6xYLexXigfAz2DtagnLd9qp9pMc0wZW0jGOjAtUwsJc3ge9D4jlRnbFYbTHpb29hl+kD9a+CBIBV9rS652/VZTnOV5oW0tv5NJiE9HT/lCb2aogw3DktwSNCGk= Received: from MN2PR20CA0052.namprd20.prod.outlook.com (2603:10b6:208:235::21) by DM6PR12MB3916.namprd12.prod.outlook.com (2603:10b6:5:1ca::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Thu, 9 Jul 2020 17:11:35 +0000 Received: from BL2NAM02FT011.eop-nam02.prod.protection.outlook.com (2603:10b6:208:235:cafe::18) by MN2PR20CA0052.outlook.office365.com (2603:10b6:208:235::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Thu, 9 Jul 2020 17:11:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=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 BL2NAM02FT011.mail.protection.outlook.com (10.152.77.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Thu, 9 Jul 2020 17:11:34 +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 069HBXaR010431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jul 2020 13:11:34 -0400 To: Roman Shpount Cc: SIPCORE References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> From: Paul Kyzivat Message-ID: <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> Date: Thu, 9 Jul 2020 13:11:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.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)(346002)(39860400002)(376002)(136003)(46966005)(86362001)(8676002)(7596003)(47076004)(786003)(956004)(82740400003)(26005)(6916009)(8936002)(31686004)(316002)(356005)(186003)(2616005)(36906005)(53546011)(70206006)(75432002)(4326008)(2906002)(478600001)(5660300002)(70586007)(82310400002)(31696002)(336012)(116284003)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2ef46f0-04b9-4278-dbb6-08d8242b222f X-MS-TrafficTypeDiagnostic: DM6PR12MB3916: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kF3LYV6w0CkkNthw7Q0saDNNS27Gq8UUsiRpBf3LXuG6usJMx35vMo+nT6daArK34mnoQ0DsALGNkKEF4br/x0Q4g/C9thbPQcg1YQJJCFUmJMmhWv8ZbvMGaUO4wlccfHVIUG4ZvSvP/nX9R88yAZRO6tivd+lEVkdjBzrngQu5SPydQtvtgTiGGcEkVuIaIcGBtRM8uoNIE0FwV6SttJq3dKmfQLzi1yGCZgI3bl/PQ6fmlF11WCvhzHcK/cYb7MDmsquAyaJyE25EN7IbV4uihegb2sT9yU8+ntNz9q6i81H96yTnzXm+a16Fw0Yb5Nh/bYsS1DSLVmsVz8ED3eTCdC25zesrRFhETrpse+JVwCkme8WVWHqpSwNzOujStEWd6N+hgGNnFRYO6UFbfUO3DzyiEhwCBeclB9T1C1hocIrxOTME/0SHauShyOPr2kR09o+QgmBur51/Obu1Mg== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2020 17:11:34.7761 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2ef46f0-04b9-4278-dbb6-08d8242b222f 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: BL2NAM02FT011.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3916 Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 09 Jul 2020 17:11:38 -0000 On 7/9/20 12:15 PM, Roman Shpount wrote: > On Thu, Jul 9, 2020 at 11:48 AM Paul Kyzivat > wrote: > > On 7/9/20 11:15 AM, Roman Shpount wrote: > > >     No, You seem to attach great importance to that point, but I > don't > >     understand the importance of that. > >     Do you argue that it is enough for each developer to address any > >     issues on their own? > > > > I am arguing that this is an old and widely deployed > specification.  It > > might not be clearly written but it is widely implemented which > resulted > > in some general consensus on how it is supposed to work. Making > changes > > to it is dangerous unless they are targeting specific issues. > > I have been fielding questions about this rfc for almost two decades. > Based on that there is widespread misunderstanding of it. > > I think it would be very helpful to at least add some overview > discussion of what this mechanism is good for and what it is not good > for. Something along the lines of what I put in my prior reply. > > > I would definitely agree to that. An informational, non-normative > section in the RFC overview can help a lot. That would satisfy me. > What I am trying to avoid is ending up with a non-obvious set of changes > to an existing specification which will act as a barrier to > implementation. Letting proxies increase SE would be an example of such > change. Upon rereading 4028 I was surprised to discover that proxies MAY increase SE to the extent necessary to conform with an increased Min-SE! I hadn't remembered that part. But AFAIK that is the only case where it is allowed. Thanks, Paul From nobody Fri Jul 10 07:56:36 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 413313A0DBB for ; Fri, 10 Jul 2020 07:56:34 -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 7NKOyy9tZmDy for ; Fri, 10 Jul 2020 07:56:32 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 947243A0CF8 for ; Fri, 10 Jul 2020 07:56:32 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id f2so2349000plr.8 for ; Fri, 10 Jul 2020 07:56:32 -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=OSHmTMtMbD1ah+kqtSDsQ0UVe7JDMde2KrQp2wMUuw8=; b=GWeqaT0S3+s+r/y2a0UyOn4YpvLMBpKBVSpUyoVSwrcO+7aMTKJRTsGDSdSJu6MFKS hGG4xqxBLJKyirsextJzzYkBo9ozbPxlp7aMhEDaY4FYrOm81S4Y/7tfirl4+KjNl+TZ nNqjrGIoCYLSCHFPyjiNKEkAYrCHRqfdmLrFrzlHmk8M6v/kK+pNROx34xr7WlPPLIYt E5RdkuqE7LWpIkSpigtxppLeKMWX5ECEWdWqDRnCZhRhpb0rEZBWK2NwiUO2gePx0lv2 59M55LhIbFMMzaWvAeZ9/SkQHTobFDHgnswv551IAJDDdVLDMXy19KMgoRDWdZZZHavx itzA== 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=OSHmTMtMbD1ah+kqtSDsQ0UVe7JDMde2KrQp2wMUuw8=; b=QSapymxSjsVCcY6vMaiEcaL3biDySCcAwtte3Hku/hPVARbf2pthxiymid/M7TYxZA DwpBGRdKQn6+JZoZAcszSWgikiJ9n28ZDnKhe2BCytZc7dh2X9b33eOLOaQEcJ84qoUI hg4z1fPfuqXivyw2vUNU9g0Jj+dJT4AtHQeAwvxtmsjEfnmgz1eey81WcR26p6rIxD7+ ByBgUiuycVSaopsHd3CyGaD0YlE0WGqvLf7opF1M9p1e/fyfa4kTyxWGi5LVwd47daBI G/qYOQ9cBQ7KKouPrpVIapIY1tBRLRYZR7WN0lxwQimxGVZTSGRUOChpq7aQtrG9k78S xCyA== X-Gm-Message-State: AOAM531ppgRLPj28DJ77rLaxKL1QdwsrFUJ1VprUXM62pOtAHvzEavsh xzZqRIzb4FlFB3dxZSw8xSTNuHE4 X-Google-Smtp-Source: ABdhPJxyQog/6LmCw2EJOeymuDTtjjfYU303OGgcNPfjTI6NGwfBzkIIn3B8gL0z6nReZLnNIYHJQw== X-Received: by 2002:a17:902:8c86:: with SMTP id t6mr5166297plo.41.1594392991985; Fri, 10 Jul 2020 07:56:31 -0700 (PDT) Received: from [192.168.128.64] (112.136.2.241.er.eaccess.ne.jp. [112.136.2.241]) by smtp.gmail.com with ESMTPSA id c139sm6203940pfb.65.2020.07.10.07.56.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 07:56:31 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> Message-ID: Date: Fri, 10 Jul 2020 23:56:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200710-0, 2020/07/10), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 10 Jul 2020 14:56:34 -0000 Paul, On 2020/07/10 0:48, Paul Kyzivat wrote: > I have been fielding questions about this rfc for almost two decades. Based on that there is widespread misunderstanding of it. I have also received an answer from you. If we don't take this opportunity to correct the ambiguity in the text, the same question will continue for another two decades. > I think it would be very helpful to at least add some overview discussion of what this mechanism is good for and what it is not good for. Something along the lines of what I put in my prior reply. I agree. Regards, Shinji From nobody Fri Jul 10 07:56: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 B8DB13A0E01 for ; Fri, 10 Jul 2020 07: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 aVTl273cPNfB for ; Fri, 10 Jul 2020 07:56:50 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0: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 629E43A0CF8 for ; Fri, 10 Jul 2020 07:56:50 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id l63so2622665pge.12 for ; Fri, 10 Jul 2020 07: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=R0GbCH6OiaAXNyVeY/lLGrid+1faJVVQDw5FYC7cA08=; b=shQ4INJAQiU/AdzT7UeQ/Tad/kchTXdYlFi52KUFUjBfOK8/buJEMsY/0H6QyWaADl duJ4qzVa8Yb+92o2XP7Lwbkh0FnArA0VUoxcEjm9tQovlWRITDSzveju2LwIw05HFH9p MO1aYF4B/+nrNdgVB+FV0xGL9tmBXYE8XoDAG2w+m6To0aQO2+ekfTZdYsL+jGXwMSnc OtIHwrumRs56G4K/dunc1aShQdow7HfyV1KP5jolslv1spnhumDeaVolPF3bCSVDUC7v PCb10WW4A7pMEO4Oe1yoFjtjOcIbYxXaiwg41n2D9dypmJFTUeF+OGyk9M4ZKMJHQvNg J/LQ== 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=R0GbCH6OiaAXNyVeY/lLGrid+1faJVVQDw5FYC7cA08=; b=HkVFEGZSBpXRhoBd1noiZbt06fY4W5EIFAxe7pfhToVCwAdjVanNxZFlJ3sNXqqh8/ d46g5swpA8VJ3pQ9mv6iZwZzR7Jsb+WPPoA4evhQZ5404ZctcdRwIKFz6WX4Z9orq334 ksWwJxA06H2vRSUwr2XxbqElRKiRabI2DIFLvLJ4FLIwyHht2/K2WIP2o7Py+rBhkUGD GE/MxQpelJiPwEwLde4VRRZ8Hg5u7a7YnWgRoezv1ARcXppOXRZDpQMnSEZgn1IzKCFt x6W2vEhO5vHVkvkJ8u17gRc5KgssddJ0WBcHTkWpjNrqGhVnXk+BGlT0Xn9QhyUNQFHB erLA== X-Gm-Message-State: AOAM532V7DaBKdrcb28W/5wixQiR+2prrfruQnQg+2nw34I15nB3Yt1g xHIwFizBkt5lrB2fh0QaXBmtycq7 X-Google-Smtp-Source: ABdhPJy6Rb6/rkMPaPX9mEZKFdLmHXQOC7AYOiWhFywO7cu2fc6rTjgOgaJeRhlR8PSStFJ0hMbHAg== X-Received: by 2002:a05:6a00:15c3:: with SMTP id o3mr60916654pfu.304.1594393009618; Fri, 10 Jul 2020 07:56:49 -0700 (PDT) Received: from [192.168.128.64] (112.136.2.241.er.eaccess.ne.jp. [112.136.2.241]) by smtp.gmail.com with ESMTPSA id m6sm6603248pjb.34.2020.07.10.07.56.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 07:56:49 -0700 (PDT) From: OKUMURA Shinji To: Paul Kyzivat , Roman Shpount Cc: SIPCORE References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> Message-ID: <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> Date: Fri, 10 Jul 2020 23:56:46 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200710-0, 2020/07/10), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 10 Jul 2020 14:56:52 -0000 On 2020/07/10 2:11, Paul Kyzivat wrote: >> What I am trying to avoid is ending up with a non-obvious set of changes to an existing specification which will act as a barrier to implementation. Letting proxies increase SE would be an example of such change. > > Upon rereading 4028 I was surprised to discover that proxies MAY increase SE to the extent necessary to conform with an increased Min-SE! I hadn't remembered that part. But AFAIK that is the only case where it is allowed. In fact, proxy is conditionally allowed to increase SE directly without renegotiation. And RFC does not specify the procedure to reject if too large. This is why I interpret the RFC does not attach importance to increase of SE. And you said, > If the Min-SE and SE are higher than one of the proxies desires, then it is pretty much out of luck. In some sense this is futile for it to complain because the timer refreshes are only part of the traffic. So, I want to know why must a proxy not increase SE-value? I think this is a very basic and important premise of RFC, but there is no specific explanation. I say again, this is not a suggestion, but a question. Regards, Shinji From nobody Fri Jul 10 07:58: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 AE8C93A0CF8 for ; Fri, 10 Jul 2020 07:58: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 4k-sHEdq8MtJ for ; Fri, 10 Jul 2020 07:58:18 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 18AEC3A0E01 for ; Fri, 10 Jul 2020 07:58:18 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id d10so2360940pll.3 for ; Fri, 10 Jul 2020 07:58:18 -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=RUn9g0G/HMVPvuC1Xs8PigqWiDGFx2fQfHirtxa7BKs=; b=azK0QmuaVT3uJehj40ebozNamPAO+NSWCJpjwCY2GhuF27oGQqE73u8mMtRyfqrl8n LGalZcM/iiEAuWATHEiizDvXF9c+KUUETcNHIEnmH+RgMOJqvYZm1qmS1zU+eJmTzteF Y/m2n0ktjGY1KraCcRCSqdHMVUM/suHjts3fek3ajDwXl1XXGTFu6tNu75qMt/LlHukh zBe788jyWGjQKCpRkVLzmf8GPzkB6AUCUrul3dKX+cpEwmuPwXqnaC76ey6WjLk27/i8 J9TvwTNTNqCVMxAkUFfkTZm7EtptPhpGRbb1SiPSGzNCt7PENK4qXrjQPhbIOVYRUKXu Eftg== 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=RUn9g0G/HMVPvuC1Xs8PigqWiDGFx2fQfHirtxa7BKs=; b=XXv4z74KjZiJciSI77+Ip+a4gNXVCNFeg95Qb936QKmrhS2weSdOxjp4GYDP1BPdHM w2sgoMFdTXlR39x2kJXxPdVubIiSzmeXL6pjnIz939Ue4fQPhlInmyrLRdL3r9PZI1mA PO9K5+A0V12dNNuDqRczuvW8Ch5Z+J8NOPha8e+hennjYxrLLHvi48Vx7IKnQI8YUmA3 WQd5g/rdQ2Aw7mnHrnlExbyYPOruM3WC8xfI7KboGplkse6htJasUb/fh23M7OFkT4uV P+8q/UKYqU6Jgbp8/6hJs74B83rzKKT/DAg8Lo2loUYAWEycTUSWyHI0IM1Q/maXoP9B SJmg== X-Gm-Message-State: AOAM530lTgmK1JvoOPe1fxDHcpDuDxfKMWX60jaVJrehU756dEr+Aums IXgPYqERSIo7GseNpa6gkXbgpOC8 X-Google-Smtp-Source: ABdhPJyjvODuGMW273GfJxhCsO/a3VHscR5Nq5bRErFPpXv3jX4STO4yiPtKVqU3npuI3WetPkpgkA== X-Received: by 2002:a17:902:ed13:: with SMTP id b19mr50620732pld.294.1594393097640; Fri, 10 Jul 2020 07:58:17 -0700 (PDT) Received: from [192.168.128.64] (112.136.2.241.er.eaccess.ne.jp. [112.136.2.241]) by smtp.gmail.com with ESMTPSA id c19sm5871854pjs.11.2020.07.10.07.58.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 07:58:17 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Roman Shpount References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> Message-ID: Date: Fri, 10 Jul 2020 23:58:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 200710-0, 2020/07/10), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 10 Jul 2020 14:58:20 -0000 Hi, On 2020/07/10 0:15, Roman Shpount wrote: > On Thu, Jul 9, 2020 at 10:42 AM OKUMURA Shinji > wrote: > >>> SE is the maximum allowed value. >> >> UAC can send again with a greater Session-Expires and Min-SE. The proxy >> CAN NOT reject the INVITE just because "Session Interval Too Large". >> Therefore SE isn't the maximum allowed value > > > Why do you think it cannot? Proxy can reject a new INVITE for any reason it > sees fit. Generally correct, if proxies don't care about UAC. I should have said: "the proxy cannot usefully reject the request, as this would result in a call failure." >> My motivation is that bis become to be more clear and error-free. > > I have zero interest in this. Session Timer (and most of SIP related > specifications) are effectively legacy specifications in maintenance mode. > You need to show serious reasons to introduce major changes at this point. Unfortunately, it seems that your empathy has not been obtained. But for me, confusable or wrong regulations are enough reasons for correction. > I am arguing that this is an old and widely deployed specification. It > might not be clearly written but it is widely implemented which resulted in > some general consensus on how it is supposed to work. If there is no documented procedure and each developer deals with the issue independently, how is interoperability guaranteed? What is "some general consensus on how it is supposed to work"? Are you not interested in considering the mysterious procedure in this WG? > Making changes to it is dangerous unless they are targeting specific issues. ISTM you think most change is dangerous, but I don't think so. > There is something to be said about redoing the entire SIP specification to > be clearer and more logical, but this would be a different and much bigger > effort. Also, I do not see that enough people have interest in doing and, > what is much more important, implementing this new SIP specification. I > understand your desire in cleaning up the Session Timer specification, but > it would effectively render the resulting document irrelevant due to most > people refusing to implement changes which are too great. My suggestions isn't as great as you think. For example, assuming we modified the regulation so that the 2xx response has an MSE header, even if one of UAC, UAS and proxy behaves according to the old regulations, no serious problems will occur. This is backward compatible. Regards, Shinji From nobody Fri Jul 10 08:26: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 7E4083A0EAE for ; Fri, 10 Jul 2020 08:26:34 -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 zu9GWq8dyl0T for ; Fri, 10 Jul 2020 08:26:33 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2087.outbound.protection.outlook.com [40.107.244.87]) (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 1569F3A0E6E for ; Fri, 10 Jul 2020 08:26:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HwHvq6AcOqd0JZs14/AB5PZ+gGRZWFS6hfpHHSQMm1URuMjojbHAc7NKxsjDudQXCfAMroz++bBCywOKSH+hppnYFxNoQkDz3e5Tfe1W7Uza0JA0ZbqS+GbVAXsW7Y0t3B0ukdl/bYBxIkVC6dlNZTlZvP16fj2Q8kIpMedAHnybSd/B4bFlcApWsZbXikUkUUCPCIUAN9cSKVTAv9W0Gwvactv+J0eVwVU1Z3Lj/UIOD77bgcQ6uZAi+k9Uj58bnE5HF74I/bXPHas1i+NMm6dLxXCGq7dTikwOneGFh6UfD5p27/ZD7bb0QEfry+e9ymtr0a0jNO2+LSgLrHW33A== 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=KDwacAeZ9cl96MGUEa/HWT322f1Sw/dvyH8ROeneK+8=; b=PQ5pB0NXQN//3Q0XrCauTfj/egTjv5KW3irNsRp5uC3MVyN0NOTzLxOyrul7CCPyhL+7Z9CdwOhVRCKbvEChCp9TKip6DVkuPXjpxM8VhGHBtKV9Cgo1iuyk4cpGVqhJJUnn9uh1n677rqxI2jjPurjr9ev2n3R9l9SJfdDM12obB9yRVfb5zy2mR34OvOPjh0mjKqPV1+KqgIz2Q/7SsEKO+TgEWaMeyGctgXHxYWikfGD1xG2SSGu4BaQrY2++ZYhbx+0Q1ww7jaLcUeRDWrCJttZXZo8pQSal4RMKDgr7aT/8ADDdb8TA2hjLlYFLo0Wnh93mbr1+R3/afyI5fw== 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=KDwacAeZ9cl96MGUEa/HWT322f1Sw/dvyH8ROeneK+8=; b=GOFw5LmJ40qTLFG0PYPdJVOByXOAps2NShSiQD99hbsMoIz5yd27wKxNZVLIUL1a4fjzqjKx2bkiXn8nM7NXKaWgF/91SmVWffzoXPSj90E0tlZUfeUEfUAyYjqwNm5/SCLuDbCY2vV0ZGyvd9v0V9zOAUGr6NpjBBw2zzKEX+k= Received: from DM5PR20CA0021.namprd20.prod.outlook.com (2603:10b6:3:93::31) by SA0PR12MB4559.namprd12.prod.outlook.com (2603:10b6:806:9e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Fri, 10 Jul 2020 15:26:27 +0000 Received: from CY1NAM02FT053.eop-nam02.prod.protection.outlook.com (2603:10b6:3:93:cafe::1) by DM5PR20CA0021.outlook.office365.com (2603:10b6:3:93::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Fri, 10 Jul 2020 15:26:27 +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 CY1NAM02FT053.mail.protection.outlook.com (10.152.74.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Fri, 10 Jul 2020 15:26:27 +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 06AFQPr0005115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2020 11:26:25 -0400 To: OKUMURA Shinji , Roman Shpount Cc: SIPCORE References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> From: Paul Kyzivat Message-ID: <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu> Date: Fri, 10 Jul 2020 11:26:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> 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:(376002)(346002)(39860400002)(136003)(396003)(46966005)(26005)(110136005)(2616005)(186003)(8936002)(2906002)(956004)(70586007)(8676002)(7596003)(70206006)(75432002)(316002)(786003)(5660300002)(53546011)(36906005)(356005)(4326008)(336012)(82310400002)(31686004)(86362001)(31696002)(478600001)(82740400003)(47076004)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4aeb5124-f760-40cc-e014-08d824e59d16 X-MS-TrafficTypeDiagnostic: SA0PR12MB4559: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f7hlWgyFQ0VaBdi3f323rDmipKiqGB7e3iiR3TC+aNsFkryTa2hoEE0BfCufjT9qg3pJroxjBSPBho0lWcT/AFIJYUohkOw6m+Y1vk4Bld/8eMxANrQ4pCkmYKXRRDDt7c9MsVqMuhWujZnawLsJKPGsUG+qoqJQlp62bEhuuZxKfjWa7a03+By8URzT3dOZmNZxy58pacrphUuckyRGmuhZ2wUxrwqnfWzRVdOaHB8mIrce1zCZo+3ilRm2GPXe0NDCgiEb+pq1iT3NUgU9fh2qa4/hLfxKuB9R1liDGjTrdYtmWJgOVtN0tD3V9wnd/J+KVnOnW1FE8BaHpN6XPZuU+7Z5Ouzomh280y4NsyZzUzLg8hfFJCZPatMVUr44UuzNGJqaWT8pqzimn1YK4P8lIDzkxWVo/db087J3OstkAWXWLofFBWuxOam4KxCt X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2020 15:26:27.2648 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4aeb5124-f760-40cc-e014-08d824e59d16 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: CY1NAM02FT053.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4559 Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 10 Jul 2020 15:26:35 -0000 On 7/10/20 10:56 AM, OKUMURA Shinji wrote: > On 2020/07/10 2:11, Paul Kyzivat wrote: >>> What I am trying to avoid is ending up with a non-obvious set of >>> changes to an existing specification which will act as a barrier to >>> implementation. Letting proxies increase SE would be an example of >>> such change. >> >> Upon rereading 4028 I was surprised to discover that proxies MAY >> increase SE to the extent necessary to conform with an increased >> Min-SE! I hadn't remembered that part. But AFAIK that is the only case >> where it is allowed. > > In fact, proxy is conditionally allowed to increase SE directly without > renegotiation. And RFC does not specify the procedure to reject if too > large. Where do you find this in 4028. > This is why I interpret the RFC does not attach importance to increase > of SE. > > And you said, >> If the Min-SE and SE are higher than one of the proxies desires, then >> it is pretty much out of luck. In some sense this is futile for it to >> complain because the timer refreshes are only part of the traffic. > > So, I want to know why must a proxy not increase SE-value? > I think this is a very basic and important premise of RFC, but there is > no specific explanation. > I say again, this is not a suggestion, but a question. If proxies along the path (and the UAS) could both increase and decrease the value of SE, then you don't have a negotiation. Rather, those further along the path have priority over the earlier ones. By having both SE and Min-SE, with SE only being reduced and Min-SE only increased, everybody on the path has input into the final result. Thanks, Paul From nobody Fri Jul 10 21:11: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 4D3633A0DF6 for ; Fri, 10 Jul 2020 21:11: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 KgsyrcgfSbRS for ; Fri, 10 Jul 2020 21:11:07 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 85ED63A0DF4 for ; Fri, 10 Jul 2020 21:11:07 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id f2so3047675plr.8 for ; Fri, 10 Jul 2020 21:11:07 -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=OJrzo4PzdXLtD3KCVr5dbbTdfmK6RYhQu1k8qg1/EvI=; b=fcXOerLiuzNdeWzC5YHyBBEwL3UYcOoEkfcYKnqPAnDuuClJ+EV/A7sqmvjcaT3YMu NnE4qRtAea6J7/RRTKLbbVPQAtJnILqR7VCl2mIzcsqRaEhWVa9SogQR6v5Hteax0XBW iNKuXceXXtdOWid+qRmKZLrtmK4MndLp4eXlZiI8ONeEMsy5k8iz9pP8UVxZOjcp2+VE TySv0Hdfk5BveH8hCpUxZTxG7N80pxnWluLSpp06AxjzZolES6kA1SuaCZYip8pWJWID MR6xDhjGQKMgAhYCLQpbsA+jGLTc1PqUX+BEvj9GUwy4uzaMVTyXLNMBZbwhBsifYaT6 q6OA== 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=OJrzo4PzdXLtD3KCVr5dbbTdfmK6RYhQu1k8qg1/EvI=; b=sXhU9MWlXvlBNh4BsuprtAPCoomdVqO4AJROf0iw3i5mYgAoJc0eO4LD9mJD+Fxvmf cwrYNEn6Sis2agIa/NPb3Y4C8Y18674kOgXYos9VOxG6qaee9UhQ0Dk93FFnli6Ev1z3 WYN4NUumFmUtaxaq7Pf6aZCOTVe1oL86ueugb//FWcxg05u8ngEiEt3TW4sbfCx5LtvW fTreemVENAihCdL7RkqA5gi32M86D2cgZ7mRY3Dv9qQPncDwLQFWu1aKFleH+GJAXgnz ReuyJJjuKibCp9CXhzLXJapnL2M6ALKPsi7Yc2xtGikQCMn8hHS8y1KAVCemFt8YC5/i JdQw== X-Gm-Message-State: AOAM531w7nKvqVg3Eqx/VTQB7ujZVYhQZBU1PLoZK9jTUp89ky2mBbuK C5iBGTXK56j7Ec1QdRnqKTQ= X-Google-Smtp-Source: ABdhPJzkwuSelgY/R06iGEYNlUETIAJlSGtHqC09N9Dq2Oc9xmUtr2uGgtHuhg4CTapMJ8nI+uiUvg== X-Received: by 2002:a17:90a:a608:: with SMTP id c8mr8506481pjq.114.1594440667018; Fri, 10 Jul 2020 21:11:07 -0700 (PDT) Received: from [192.168.128.64] (112.136.2.241.er.eaccess.ne.jp. [112.136.2.241]) by smtp.gmail.com with ESMTPSA id g22sm7269502pgb.82.2020.07.10.21.11.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 21:11:06 -0700 (PDT) From: OKUMURA Shinji To: SIPCORE Cc: Paul Kyzivat , Roman Shpount References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu> Message-ID: <36562af9-bb48-74b1-0ffa-a90c3ad45c5b@gmail.com> Date: Sat, 11 Jul 2020 13:11:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 200710-8, 2020/07/11), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 11 Jul 2020 04:11:09 -0000 Hi, On 2020/07/11 0:26, Paul Kyzivat wrote: > On 7/10/20 10:56 AM, OKUMURA Shinji wrote: >> On 2020/07/10 2:11, Paul Kyzivat wrote: >>>> What I am trying to avoid is ending up with a non-obvious set of changes to an existing specification which will act as a barrier to implementation. Letting proxies increase SE would be an example of such change. >>> >>> Upon rereading 4028 I was surprised to discover that proxies MAY increase SE to the extent necessary to conform with an increased Min-SE! I hadn't remembered that part. But AFAIK that is the only case where it is allowed. >> >> In fact, proxy is conditionally allowed to increase SE directly without renegotiation. And RFC does not specify the procedure to reject if too large. > > Where do you find this in 4028. P.13 If the value of the Session-Expires header field is lower than the value of the Min-SE header field (possibly because the proxy increased the value of the Min-SE header field, as described below), the proxy MUST increase the value of the Session-Expires header field to make it equal to Min-SE header field value. Of course, negotiation with downstream proxies and UAS will occur. >> This is why I interpret the RFC does not attach importance to increase of SE. >> >> And you said, >>> If the Min-SE and SE are higher than one of the proxies desires, then it is pretty much out of luck. In some sense this is futile for it to complain because the timer refreshes are only part of the traffic. >> >> So, I want to know why must a proxy not increase SE-value? >> I think this is a very basic and important premise of RFC, but there is no specific explanation. >> I say again, this is not a suggestion, but a question. > > If proxies along the path (and the UAS) could both increase and decrease the value of SE, then you don't have a negotiation. Rather, those further along the path have priority over the earlier ones. > > By having both SE and Min-SE, with SE only being reduced and Min-SE only increased, everybody on the path has input into the final result. I understand the basic policy, but when the UAC that received the 422 response retransmits the INVITE with a larger SE and MSE set, the proxy cannot reduce the SE. I think the result will be the same as if the proxy increased SE. Regards, Shinji From nobody Sat Jul 11 13:15: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 7E9373A00DF for ; Sat, 11 Jul 2020 13:15:07 -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 i3LjuGzryPxF for ; Sat, 11 Jul 2020 13:15:05 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2056.outbound.protection.outlook.com [40.107.244.56]) (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 D00553A00C9 for ; Sat, 11 Jul 2020 13:15:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BRpO1OcGIfckBkU1A6PFGyMJ9vOaUgJ8L7Jp3FoXw/nFU52kxR3//bXnTk18RfuI+AjvfeSru7F2EYy1r15LAZGvukpxzAszEphqdoU383Zo2AiOj/7JsvQ0o5B4NJIY4Fj8T1vJaNNO9NYXSJ5DPrMv7o2/vYFQA0EgkKWPo9lU/ep3PDb91neDcivY/LdtqZ5R/RE3RAzCNRRHdtD4Yoj+oDzRUvY2Ts7utQG+xYC76lZWaoxvJu3q0f0PYKD/n2lRilk3f54dcDft50INHRFv27Cs9dojR12o0nH6MmGtFYyO9VmNOoEjOamM/U/Mj4JuwdKFMkJ499yCsq1vbQ== 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=hUWyXKOV4IFU09EZ/rRbLx03TCqhDoBkjSyMgTejqP4=; b=kU9h/GmJVDm8l2XknQJ7VlsKcy3IruLAMO6gPi2wemXmdfbNNGOiYJQVW2AsSei4F0FUO2ckMNbjb8PW/Cw36iEaOf9KkbxgZ3XPE+EFcJl8NepucoKN8blhchdvjoiS+72I+NrDeCs0upv7yxbwv+TakMFL9AzfNAzXmjQJQrELQ72mCcRL0SxVLvtb+NGMfxyio2+Yq3NnVmv/zkarO/PlcCYAtkuRfw1tbwGzJcoXxO1KtfSYI8r0MuE6wJ5R47XzVWMmT3uy+fWOttHcy9rppukXAImbpWdUmcGzYwundyLXo8povDYejIRphblTGoZ7yip+fmJdjGL6Bn4Bhw== 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=hUWyXKOV4IFU09EZ/rRbLx03TCqhDoBkjSyMgTejqP4=; b=Ja/jxv8MbNWaRXqYtBJXl4dsBHMFAh2vZhdyPi/EP97TdXZ5khmPYkIkqvCdRgnhhPvqz0AeRoiMU6YdCGOSmCDXMaRGMC7Q/tfPUTMaFlIySMRi7L5oO45r2ZzjU4JmaiauuUkg7xCOnBT2SiAOZgCSutjZ/3Z1qKjg9KsTyxs= Received: from SN4PR0501CA0047.namprd05.prod.outlook.com (2603:10b6:803:41::24) by DM6PR12MB4249.namprd12.prod.outlook.com (2603:10b6:5:223::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24; Sat, 11 Jul 2020 20:15:04 +0000 Received: from SN1NAM02FT044.eop-nam02.prod.protection.outlook.com (2603:10b6:803:41:cafe::ff) by SN4PR0501CA0047.outlook.office365.com (2603:10b6:803:41::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9 via Frontend Transport; Sat, 11 Jul 2020 20:15:04 +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 SN1NAM02FT044.mail.protection.outlook.com (10.152.72.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Sat, 11 Jul 2020 20:15:04 +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 06BKF1kK026199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Jul 2020 16:15:02 -0400 To: OKUMURA Shinji , SIPCORE Cc: Roman Shpount References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu> <36562af9-bb48-74b1-0ffa-a90c3ad45c5b@gmail.com> From: Paul Kyzivat Message-ID: <004e3388-9a73-376b-5b37-44799da1d0db@alum.mit.edu> Date: Sat, 11 Jul 2020 16:15:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <36562af9-bb48-74b1-0ffa-a90c3ad45c5b@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:(396003)(136003)(346002)(376002)(39860400002)(46966005)(36906005)(31686004)(956004)(2616005)(31696002)(70586007)(336012)(70206006)(26005)(75432002)(7596003)(82310400002)(47076004)(356005)(8676002)(83380400001)(8936002)(82740400003)(86362001)(5660300002)(786003)(316002)(4326008)(110136005)(478600001)(53546011)(2906002)(186003)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4ff42b90-00d1-49c9-101e-08d825d71927 X-MS-TrafficTypeDiagnostic: DM6PR12MB4249: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 046164D5C4 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Y3Ubd5bo4pN+AupUKN1vcrY0pSJrwvdkKQahDF+a9GVQG5H2LlJIhui1uVc7TroEub5BtUY+xIfvCcfKp1bgySeGEnGrQkoB+vMEm6ltWjcipPjv/+jzTR2JUEeMoq1B9cdcFxWGBWvFpyMaD9SDQ2PfSZ7zlz5lFHz2pVYQYImaNJaADcBNUUUD+dwJK8NWhMjkeSG3TTEhLZkzdWd2aqxoeKg86TEhKj2kfENTYC79bfJ9wCw+i2B4/1jxr1L5eK/UHNLIxE5duqXJazLoISSZhN1BNhGpoYz9p2zB64OJYrdT1HYtUhL/49kjpoqUJbTD759GdgHRXfqnZP9d0fCD5qxNtYhjJJIFaFFJTCrw5xoNjUY89tLYAZGEbSUCY0gpO2YB95yS902BRjvMF6Rs4GBkbWMzs0LQdyzOCi9aQdO0OVXh/kS3HBoa/dqq X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2020 20:15:04.0403 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4ff42b90-00d1-49c9-101e-08d825d71927 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: SN1NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4249 Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 11 Jul 2020 20:15:08 -0000 On 7/11/20 12:11 AM, OKUMURA Shinji wrote: > Hi, > > On 2020/07/11 0:26, Paul Kyzivat wrote: >> On 7/10/20 10:56 AM, OKUMURA Shinji wrote: >>> On 2020/07/10 2:11, Paul Kyzivat wrote: >>>>> What I am trying to avoid is ending up with a non-obvious set of >>>>> changes to an existing specification which will act as a barrier to >>>>> implementation. Letting proxies increase SE would be an example of >>>>> such change. >>>> >>>> Upon rereading 4028 I was surprised to discover that proxies MAY >>>> increase SE to the extent necessary to conform with an increased >>>> Min-SE! I hadn't remembered that part. But AFAIK that is the only >>>> case where it is allowed. >>> >>> In fact, proxy is conditionally allowed to increase SE directly >>> without renegotiation. And RFC does not specify the procedure to >>> reject if too large. >> >> Where do you find this in 4028. > > P.13 >    If the value of the Session-Expires header field is lower >    than the value of the Min-SE header field (possibly because the proxy >    increased the value of the Min-SE header field, as described below), >    the proxy MUST increase the value of the Session-Expires header field >    to make it equal to Min-SE header field value. > > Of course, negotiation with downstream proxies and UAS will occur. OK. But that only allows increasing up to the value of Min-SE. It doesn't otherwise allow increasing SE. >>> This is why I interpret the RFC does not attach importance to >>> increase of SE. >>> >>> And you said, >>>> If the Min-SE and SE are higher than one of the proxies desires, >>>> then it is pretty much out of luck. In some sense this is futile for >>>> it to complain because the timer refreshes are only part of the >>>> traffic. >>> >>> So, I want to know why must a proxy not increase SE-value? >>> I think this is a very basic and important premise of RFC, but there >>> is no specific explanation. >>> I say again, this is not a suggestion, but a question. >> >> If proxies along the path (and the UAS) could both increase and >> decrease the value of SE, then you don't have a negotiation. Rather, >> those further along the path have priority over the earlier ones. >> >> By having both SE and Min-SE, with SE only being reduced and Min-SE >> only increased, everybody on the path has input into the final result. > > I understand the basic policy, but when the UAC that received the 422 > response retransmits the INVITE with a larger SE and MSE set, the proxy > cannot reduce the SE. I think the result will be the same as if the > proxy increased SE. But this requires that the 422 be issued, and that the UAC be willing to retry with the values it contains. Until we get to this point everybody gets to have their vote counted. The bottom line is that when there is a conflict, with some parties requiring that SE be larger and some requiring it to be smaller, the larger preference wins. This is effectively valuing efficiency of processing over cost of saving state longer, or if you prefer, valuing UAs over proxies. But this tradeoff only occurs if there is no happy medium that all can live with. Thanks, Paul From nobody Sat Jul 11 15:27:36 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 348F43A08D6 for ; Sat, 11 Jul 2020 15:27:35 -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 Qb2Lj63Spzht for ; Sat, 11 Jul 2020 15:27:33 -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 C691E3A08CD for ; Sat, 11 Jul 2020 15:27:33 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id t18so6822558otq.5 for ; Sat, 11 Jul 2020 15:27:33 -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=ayJVPN66+3xivGELsXK/QVM9egLx5GTfevoP3/lBKR0=; b=ykI/2ZxWBhF0mKgHVzdmSjo7h0RbA/s1JM1PBjlU3cFY3nd3klSco//h/qoZ0C2HYc M19sWDLIFUC9EtrIF/cpTRgBsD3guRPEKboUJti3sc/q8zChgEEkl8dQLgER2xAc5zh5 dK5mQc6ais16ccw0/D0yz/MxCDoUxLNMkK49lB5qnAqvq4X1718fqFfiNTQ2f7bxhjGu qi2di9lUj9XOSjC8HaHFUAppOfSLMHRNNNDm9IOaHeAAs//Mafb0RTAx6KHZRXUGnOdE DudH/lhOiPhNsqTWd7OeX+wX1KEtX6seRzd53KZOB4O0e3kePX7IKR29SH8Y6VVowufa v+Hg== 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=ayJVPN66+3xivGELsXK/QVM9egLx5GTfevoP3/lBKR0=; b=SIDvBzB4HUVmZSl8JqFT85WDoJwUfQMLFLQfS3a4ZH0662zbgOaYPwMZx6Wl7P+LbW VE35YwnH2rMSnvQZgBHm2tkc4cgCtqWgjSmgcJaCpM9X+D46rFdxZoPMxWlPsZu7ZYWO sRT25kNdF/KpmC1OjY9udckFgDb9shUN+JTUJZjCJs2onJXF+5ZhzyoQGEArnLE7m7qO glhVdASirYKhxYXyufSLGp7fYVb8e0gI1u/swjt08H+3DpKmd++uoDm+4zN4YJyfSKPL 6FDxRu8kj23vWRVXjw/z2mRXom221nozetF/lyYJBC3YF+TLS65Yrr7EWMrtcyT8dui5 k8tA== X-Gm-Message-State: AOAM533I9lkcDRZS542PNLMWsFh0yA43P5C24W0xeHzaxRq7E6HRzen0 wilmcwxqTMoPYWUJpP1xTYgitmp3p4U= X-Google-Smtp-Source: ABdhPJyZdj1wHM4nUe6D6y/s5C6+eISRwYOZqqrbXZ6rFQGabfGvXGNZYEpcSoL04fVpp49Lnth/ww== X-Received: by 2002:a9d:8e4:: with SMTP id 91mr49701653otf.38.1594506452471; Sat, 11 Jul 2020 15:27:32 -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 r22sm2143724ooq.37.2020.07.11.15.27.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jul 2020 15:27:31 -0700 (PDT) Received: by mail-oi1-f177.google.com with SMTP id 12so7909067oir.4 for ; Sat, 11 Jul 2020 15:27:31 -0700 (PDT) X-Received: by 2002:a54:4e1d:: with SMTP id a29mr9241966oiy.139.1594506450724; Sat, 11 Jul 2020 15:27:30 -0700 (PDT) MIME-Version: 1.0 References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu> <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu> <36562af9-bb48-74b1-0ffa-a90c3ad45c5b@gmail.com> <004e3388-9a73-376b-5b37-44799da1d0db@alum.mit.edu> In-Reply-To: <004e3388-9a73-376b-5b37-44799da1d0db@alum.mit.edu> From: Roman Shpount Date: Sat, 11 Jul 2020 18:27:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: OKUMURA Shinji , SIPCORE Content-Type: multipart/alternative; boundary="000000000000966d5205aa31f65a" Archived-At: Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1 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, 11 Jul 2020 22:27:35 -0000 --000000000000966d5205aa31f65a Content-Type: text/plain; charset="UTF-8" On Sat, Jul 11, 2020 at 4:15 PM Paul Kyzivat wrote: > On 7/11/20 12:11 AM, OKUMURA Shinji wrote: > > P.13 > > If the value of the Session-Expires header field is lower > > than the value of the Min-SE header field (possibly because the proxy > > increased the value of the Min-SE header field, as described below), > > the proxy MUST increase the value of the Session-Expires header field > > to make it equal to Min-SE header field value. > > > > Of course, negotiation with downstream proxies and UAS will occur. > > OK. But that only allows increasing up to the value of Min-SE. It > doesn't otherwise allow increasing SE. > This is a very specific case where UAC does not support Session-Timer. In other cases proxy should not increase Min-SE over the value of Session-Timer and should fail the request with 422. It is not the reason to drop session timer negotiation when both UA actually support this. _____________ Roman Shpount --000000000000966d5205aa31f65a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 11, 2020 at 4:15 PM Paul Kyzi= vat <pkyzivat@alum.mit.edu&= gt; wrote:
On 7/11/20 12:11 AM, OKUMURA Shinji wrote:
> P.= 13
>=C2=A0 =C2=A0=C2=A0 If the value of the Session-Expires header field is= lower
>=C2=A0 =C2=A0=C2=A0 than the value of the Min-SE header field (possibly= because the proxy
>=C2=A0 =C2=A0=C2=A0 increased the value of the Min-SE header field, as = described below),
>=C2=A0 =C2=A0=C2=A0 the proxy MUST increase the value of the Session-Ex= pires header field
>=C2=A0 =C2=A0=C2=A0 to make it equal to Min-SE header field value.
>
> Of course, negotiation with downstream proxies and UAS will occur.

OK. But that only allows increasing up to the value of Min-SE. It
doesn't otherwise allow increasing SE.

<= div>This is a very specific case where UAC does not support Session-Timer. = In other cases proxy should not increase Min-SE over the value of Session-T= imer and should fail the request with 422. It is not the reason to drop ses= sion timer negotiation when both UA actually support this.

_____________
=
Roman Shpount=C2=A0
--000000000000966d5205aa31f65a-- From nobody Sun Jul 26 11:42:04 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 754553A13A8 for ; Sun, 26 Jul 2020 11:42:03 -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=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 fBj9RuAYhqOu for ; Sun, 26 Jul 2020 11:42:01 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 0D08D3A13A7 for ; Sun, 26 Jul 2020 11:42:01 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id g22so3294882vke.9 for ; Sun, 26 Jul 2020 11:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HdmojTqa0/hUznyjlr1GWXCeOcxn+t/VbdtobjvcBRM=; b=YLT1dzuxdswJ0kCThDTYjTPJQsQJciwLzeu0ZBLu74YbQ4x6csiu5Fia8hjiHa1bCd cc3SeJ0swqdR41uPyilEc4/fQEHEmm24KU8dir107lVFXLdngYBzMwZZFd9ojqBA7INZ K/1OSFqxbD9txgRC2M3odJe6yTADVgCY/TWnBrxAhJPuaYI8tguSoKu8YU7aDrb79kNH /ZfqJKmJFXdQJgCYmguqbB6Jn+5Xt5oXLoTreyVwBfCwQczRYBrnREmp9lEISA3w2oRP lJgs5fKEeqmTCnumNi9mc5AufuOdWWt7arBSIYur4Qkh2qr5ZMe7hNd9cyL+ttFTp45w MLew== 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; bh=HdmojTqa0/hUznyjlr1GWXCeOcxn+t/VbdtobjvcBRM=; b=AR1p5pvvYjTdJXSMbLfWM2cAUzYI32I/YZonOEsmOlTMr0jGCsDImzllkS+8mKtswz HYqBfIwfJdDkCeK89ZTf/DAsppT2RyJPieF7BjktP4P/Lo7Fo504SBLxL8tXsoSTQayM LrN5u/wZwbzQNSXZrKfR+1NnuVqbJOax49OeKvvtkwjaehh2WO83EbqWCZZ3EY2HZtvw 7K1JtavspYzfxvvOwmFRlCvUN/U07+G+/PTERle1gN2gYFUOI9zAh+tw/b5lZ5zmBgEe M4rooGsxWZaMDbW1f2xizU6U9FP2oG1/VNSUBjn4m03G17LIjAxDumufI9IltvU936qd X9dg== X-Gm-Message-State: AOAM532UbcSwvbYHXkPSXeB+6GHR7usF6g5MwocpiJk3s/z+iV0Xvdlo odKWcCdDoLCNZPcWDjk4V46L+Sw3sf/oh6HgsfXB/g== X-Google-Smtp-Source: ABdhPJw7eBCVlDAZm1Fg6WhDGBva2sajp6HQ038/L4rANzF8Xk9xLa8RzYLobDTpntFtgwyqFpboWc1k543oRAQQX9Y= X-Received: by 2002:a1f:9a85:: with SMTP id c127mr14391123vke.8.1595788919658; Sun, 26 Jul 2020 11:41:59 -0700 (PDT) MIME-Version: 1.0 References: <159562615817.8487.8157656164577705814@ietfa.amsl.com> In-Reply-To: <159562615817.8487.8157656164577705814@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 26 Jul 2020 11:41:49 -0700 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000b15d1705ab5c8f13" Archived-At: Subject: [sipcore] Fwd: WG Action: Formed Automatic SIP trunking And Peering (asap) 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, 26 Jul 2020 18:42:04 -0000 --000000000000b15d1705ab5c8f13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of possible interest to this community. -MSK ---------- Forwarded message --------- From: The IESG Date: Fri, Jul 24, 2020 at 2:29 PM Subject: WG Action: Formed Automatic SIP trunking And Peering (asap) To: IETF-Announce Cc: , , The IESG , < dispatch-chairs@ietf.org> A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. Automatic SIP trunking And Peering (asap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Adam Roach Gonzalo Salgueiro Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: asap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Group page: https://datatracker.ietf.org/group/asap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/ The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods o= f interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often unclear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks. As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individuall= y or with enterprise equipment manufacturer and service provider support teams. Consequently, there is an increase in the time taken to deploy SIP trunking between enterprise and service provider networks. The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, encapsulates sufficient information to set up SIP trunking with the service provider network. In addition to defining a descriptive capability set, the ASAP working group will define a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. The aforementioned deliverables of the ASAP working group are collectively referred to as =E2=80=9CSIP Auto Peer=E2=80= =9D. The scope of the ASAP working group is: * A capability set that encapsulates sufficient information to ensure smoot= h IP peering between enterprise and service provider SIP networks. * A data model for the capability set. * An HTTPS-based transport mechanism for the capability set. * A mechanism to discover the server(s) in the SIP service provider network that hosts the capability set. * A mechanism to extend the data model to allow the encoding of proprietary parameters. The following are out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network. The group will produce: * Specification for SIP Auto Peer This group will co-ordinate with the SIPCORE working group and the SIPConnect efforts carried out by the SIP Forum. Milestones: Jun 2021 - SIP Automatic Peering specification submitted for publication to the IESG. --000000000000b15d1705ab5c8f13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of possible interest to this community.
-MSK

---------- Forwarded message ---------
From: The IESG &l= t;iesg-secretary@ietf.org>= ;
Date: Fri, Jul 24, 2020 at 2:29 PM
Subject: WG Action: Forme= d Automatic SIP trunking And Peering (asap)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: = <asap-chairs@ietf.org>, = <asap@ietf.org>, The IESG <iesg@ietf.org>, <dispatch-chairs@ietf.org>

<= br>A new IETF WG has been formed in the Applications and Real-Time Area. Fo= r
additional information, please contact the Area Directors or the WG Chairs.=

Automatic SIP trunking And Peering (asap)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Gonzalo Salgueiro <gsalguei@cisco.com>

Assigned Area Director:
=C2=A0 Murray Kucherawy <superuser@gmail.com>

Applications and Real-Time Area Directors:
=C2=A0 Barry Leiba <barryleiba@computer.org>
=C2=A0 Murray Kucherawy <superuser@gmail.com>

Mailing list:
=C2=A0 Address: asap@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /asap
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/asap/

Group page: https://datatracker.ietf.org/group/asap/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-asap/

The deployment of a Session Initiation Protocol (SIP)-based infrastructure = in
enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between=
enterprise and service provider networks is replacing traditional methods o= f
interconnection between these networks, such as analog lines and
time-division multiplexing (TDM)-based digital circuits.

Currently published standards provide a strong foundation over which direct=
IP peering can be realized. However, given the sheer number of these
standards, it is often unclear which behavioural subsets, extensions to
baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP=
service provider network. This lack of context often leads to
interoperability issues between enterprise and service provider SIP network= s.
As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individuall= y
or with enterprise equipment manufacturer and service provider support team= s.
Consequently, there is an increase in the time taken to deploy SIP trunking=
between enterprise and service provider networks.

The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an
enterprise network, encapsulates sufficient information to set up SIP
trunking with the service provider network. In addition to defining a
descriptive capability set, the ASAP working group will define a data model=
for the capability set, a service discovery mechanism and a transport
mechanism for the capability set. The aforementioned deliverables of the AS= AP
working group are collectively referred to as =E2=80=9CSIP Auto Peer=E2=80= =9D.

The scope of the ASAP working group is:

* A capability set that encapsulates sufficient information to ensure smoot= h
IP peering between enterprise and service provider SIP networks.

* A data model for the capability set.

* An HTTPS-based transport mechanism for the capability set.

* A mechanism to discover the server(s) in the SIP service provider network=
that hosts the capability set.

* A mechanism to extend the data model to allow the encoding of proprietary=
parameters.

The following are out of scope:

* Extensions to SIP that enable an enterprise network to solicit and obtain= a
descriptive capability set from a SIP service provider.

* A workflow/mechanism that allows service providers to directly configure<= br> devices in the enterprise network.

The group will produce:

* Specification for SIP Auto Peer

This group will co-ordinate with the SIPCORE working group and the SIPConne= ct
efforts carried out by the SIP Forum.

Milestones:

=C2=A0 Jun 2021 - SIP Automatic Peering specification submitted for publica= tion to
=C2=A0 the IESG.



--000000000000b15d1705ab5c8f13-- From nobody Fri Jul 31 10:37:32 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 B1A6B3A0BF0 for ; Fri, 31 Jul 2020 10:37:30 -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, 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=team.neustar header.b=RIGAMDJg; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=neustar.onmicrosoft.com header.b=FAeb58JC 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 I6pKmRgLzS7q for ; Fri, 31 Jul 2020 10:37:26 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 CFA233A0E63 for ; Fri, 31 Jul 2020 10:37:02 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06VHYCg7010132 for ; Fri, 31 Jul 2020 13:37:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=team-neustar; bh=K/PbBPDGUT0TXX6DRRxlkgG5OTeI8UwFIzC7xI4OzL8=; b=RIGAMDJgXYOn7bPcPx5ArFPJb0XKEml/OES383w9Au1UyEobzVvTluGj0QF5cz3p35iq J26hNrl6f0cGqPzBxGJa1RU8s+7djtqoG6vldEfc5tqWshbiG50RKXybAK/BxP4ts1nm dmXDhPLQhEI135QEO6NLKIoCnicdsvpu+QAb5xTvy6hqEDkzwmEhzPN/200chlGiiJmo IVJgP/ZVMHaCBxTGpynaJGxeHORbPfOTHrlbgehviLRBJLQTW3vSrqi2ConkXdU53NXo ids2Q+iIrlFAmFIvyjEVuOSOvYZvYgDhcjRQXAVFH7HwxdvV8Wxe8LZp8NtZs4sfzMpB 1g== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2056.outbound.protection.outlook.com [104.47.38.56]) by mx0a-0018ba01.pphosted.com with ESMTP id 32gguwm19u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jul 2020 13:37:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZF5DKB9uK0vI8jmgN7p8YTs57lQKQs1wNOHFeoj5afvtBvRFRsyCKnVQk3gLyqDXmgY3HQrClOgmm8GJ2DkAt01qbWkXm0hQUhQ2peqThSiZVTcSaNRUz0+wunD2/IvGZ3AJSqksCTFz0NG97p31FbbsiyAWKesdpKkOAKEsA5k5x6nDg8sMt1K5l+2/zHtwYDWY23u3niK/3TtmhUQUJ/aLbgDi/ygf3LCezzNZFQAgWwGafo1dko5z5jXYziZ2Zf1XrK0nAlaoo9QUfhoqYhceJW8O8Ll987VHqpFcSwpq4c/LNy7oKz4cY4Di7pGF2F05umcGaVtymSyOL/FjPQ== 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=scAQUSS7S9ObTEG00rQawnmLHJoOtwwpYFVLPVM+hfE=; b=a0Im0px8k7/LT3gOJdXHN7dQYFiNV5v9jmD8pE0iJD7/7r6IGBjxgquywhZm61iIaKFqOEr2DhGN4+cqSCvFhK0Y6ZYq6AdJ3SJIZGUW/gXnVAeIT2n+3niTmKJ+9jsuZH/MPB8Y5jwc/JbNiVrQVRwI3pNhBpxObpMQ1uws7huM3aIdWnNg++6QSevcRErTDaakRM8WTZYr1O/EKwRjNwB7QdOFxTU/GjAJv+NCCBxeP8hm6MC6cCmpXpUy0Yi99vwbzKKloMeLRVGYVje3hU3v8r07UkiRSwKrGPdgiHTqv4KXUkRaqy6aWynIk2U45wCF2P2qvhrP4DfGnQ0T5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.neustar; dmarc=pass action=none header.from=team.neustar; dkim=pass header.d=team.neustar; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.onmicrosoft.com; s=selector1-neustar-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=scAQUSS7S9ObTEG00rQawnmLHJoOtwwpYFVLPVM+hfE=; b=FAeb58JC8hTCnokdNSKNbRktBGhTyBp4ccbAENcYYQONH6PeoocgHkeZUxC1E09dmUozmr0aYy/rfK+dW0PAf/IGOAM49KWU9YgZl/nfGF/HQ1J3igIBmqQZHDLO1nldLf8HgxNkyyJZ0WxSndNjtwASXAFh4vD63ptRDZD8In4= Received: from BY5PR17MB3569.namprd17.prod.outlook.com (2603:10b6:a03:1b9::20) by BY5PR17MB4036.namprd17.prod.outlook.com (2603:10b6:a03:23c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Fri, 31 Jul 2020 17:36:59 +0000 Received: from BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15]) by BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15%5]) with mapi id 15.20.3239.020; Fri, 31 Jul 2020 17:36:59 +0000 From: "Peterson, Jon" To: "sipcore@ietf.org" Thread-Topic: draft on rich call data and Call-Info Thread-Index: AQHWZ2ExQtFvv+YumkmWEeP6FPEu6A== Date: Fri, 31 Jul 2020 17:36:59 +0000 Message-ID: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=team.neustar; x-originating-ip: [108.208.24.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c8daefa-95a0-48e7-cc49-08d8357853e5 x-ms-traffictypediagnostic: BY5PR17MB4036: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: alJ2TBuGXJFVMkhJ9nSe30jsTgx2XhgpNrc0WhHGUsQCe5TfqJJGIL77i5aCktPdQzcThNvQlCHSlZ7CAMPDEsBSXLOE2o0/uWIOYG8qIR93b7Hb7TGLEJGeMfrAcK2417p5nh9YZgDFE93eoqbTF3sqRiT6NwcBlXs9qlPEA6YR45eljjZrU4fncqM/nlNtLAdIqbjGrdVkApZeQsNzuGzjhju40k7v98z38MJgShW0ayh0oCfKpMtMdAVp/kIb+tm9pAum3n+spXUzF8HHtHSFKtk51CtFf1vqyvqLCSsX7ZxhEqUAtUr41wNkihBPedQ4jdD44EqtHj263I3GzKT9fmJDiT4p7h+wh0oKiwAlveRBl5R+oCtXQQuLIvtdMAjpN4ILSWMeU3WpIKqaeOYcNTVpZAPYhAaegNmwfPX057QIUXjAKm6vqNZWGF2FyjTv4rorBkQNPsXm9hwQjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR17MB3569.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(966005)(6916009)(6486002)(5660300002)(316002)(4744005)(33656002)(83380400001)(6506007)(8676002)(8936002)(478600001)(2906002)(26005)(6512007)(186003)(86362001)(66446008)(64756008)(66556008)(76116006)(66946007)(71200400001)(66476007)(2616005)(46492007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KsQ77jePhe+RCs3/nypvib1uGL5eBeI5C1LPMpBxHrQQEQ1/UUeeiA3mWFUeNmB9TwiE+OnCDTLDXiGAFO6z3QEeKT1uLHZnXTXcdWSjORluY165uNitjo1M1zEG0pTOPPe1991mMiFhdqVv+KT3K7miCL2nYrSn/8/ckEnLo+DbsUhFdpvNym9xdEAGxulOF1TDKLz4eSotZJmhkTywMJngp07yDSZyndL6iGGJnHLZyOcNRsd64Iv0lGYlY2z4WFfB5JYVQKEhZawCq+R2t2TVmdpoflCJEVyKh/l6B7Purg+jvrq33Kkj42m9xC4gepeHj+9Gbh2TpMXgVwFkKqzAKp6VVEwfOMZk07LXiqX7maUCXFqwTGEoAhzfW85iQ27hTpwPHqwgDOBYqvnJsko1/dk8v0AeUAnwLFF3HXAiUVQrblefJ+xxf7anWKVja55tpZOE4PUfRowFXh8IIx35r6fbNfN0ieKBZGkynv7YcgpYU6aOAkzdnsEdtW+rFVDgpmtB2OQJ4IIcNZPDh67o7qsOFW+cmUwGW6xxfmsg21Z7AFzB8VE+7ac5r5cX2i7/iOa6I0L88iBx+iYJSh31KzkygPkfkNzDtOdkHo8x72ZS4ww4szgG0qzJ6lcu/6PqxP1m61IvryBLliyn3w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: X-OriginatorOrg: team.neustar X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR17MB3569.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c8daefa-95a0-48e7-cc49-08d8357853e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 17:36:59.1812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 73a2bbc1-f307-47c4-8f94-5f379c68bc30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3nbTmIb+hCREAiXXHcsarS9X9UiUPVllJUakJULTOvwWlJy8rzfBYdsAXMon2MD59hG1pFsq4g5vA27TCQ5iKkGICFZVB+d11bQdO4vlpAE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR17MB4036 Content-Transfer-Encoding: Quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-31_06:2020-07-31, 2020-07-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007310131 Archived-At: Subject: [sipcore] draft on rich call data and Call-Info 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, 31 Jul 2020 17:37:31 -0000 Hello, Chris Wendt and have a draft that has split off from our work toward delive= ring rich call data (RCD) in the STIR WG. This is for carrying data element= s like a caller name, a jCard, call reason, and potentially related element= s that will be rendered to the called party to help them decide if they sho= uld pick up the phone. We ultimately decided that, instead of doing a one-o= ff for conveying RCD within the PASSporT object, we should instead focus on= how that information is best relayed in baseline SIP, and keep the STIR pa= rt of the problem confined to signing over those fields as they appear in S= IP requests. So this draft is the core SIP part: https://urldefense.com/v3/__https://tools.ietf.org/html/draft-wendt-sipcore= -callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_mM= t9ysIG4-Yz2itA0$=20 We'd be interested in the thoughts of the SIPCORE WG about the fundamental = approach here, and ultimately if there's interest in adopting this as a WG = item here. Thanks! Jon Peterson Neustar, Inc,.