Re: [Insipid] Requirement for Intermediaries to Update Session ID for other parties

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Tue, 07 June 2016 19:20 UTC

Return-Path: <pgiralt@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1B612D504 for <insipid@ietfa.amsl.com>; Tue, 7 Jun 2016 12:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJb5f2qpdIwy for <insipid@ietfa.amsl.com>; Tue, 7 Jun 2016 12:20:11 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AD812D0C5 for <insipid@ietf.org>; Tue, 7 Jun 2016 12:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3637; q=dns/txt; s=iport; t=1465327211; x=1466536811; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f3XGkGkl3o49IpkbppVPmk7ML3ciVRrZ9dnHelP2PGY=; b=kgH0FMMdue94VY8d34SK9QwgsVCmLYK4SOHpSKM2G4c8GDNUErLyBU96 9UZkmW63xuSn4nA30R81ILAAJLfBrdAievv+A7AOpq+Hz9Udg/86wFZbs GaCOrQMepbMa9zteh235H3PW7hgkqfwYYUoJIUTgBTdLueU32eUZIMhMd E=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBQC1HVdX/5xdJa1cgz6BWbpmgXmGE?= =?us-ascii?q?wKBQjoSAQEBAQEBAWUnhEYBAQMBI1YFCwIBCEICAjIlAQEEDhOIGQirYZEbAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6GJ4F3CIJOh0Ergi4FmEsBgy2BaYkQgWqNN?= =?us-ascii?q?oY9iSEBJQQrggIFHBaBNYl+fwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,434,1459814400"; d="asc'?scan'208";a="112588362"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 19:20:10 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u57JKADf015632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jun 2016 19:20:10 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 15:20:09 -0400
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Tue, 7 Jun 2016 15:20:09 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Brett Tate <brett@broadsoft.com>
Thread-Topic: [Insipid] Requirement for Intermediaries to Update Session ID for other parties
Thread-Index: AdHA2312D/wUckGRTgeNOtz38IHE2AAN6GUA
Date: Tue, 7 Jun 2016 19:20:09 +0000
Message-ID: <BB58EF31-8935-456E-9783-BBFCF418F472@cisco.com>
References: <6b8d81020946d1e12b87064387164e51@mail.gmail.com>
In-Reply-To: <6b8d81020946d1e12b87064387164e51@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.96.60]
Content-Type: multipart/signed; boundary="Apple-Mail=_FE932CE8-E3D0-4152-9BE1-4ECA61161778"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/k3iKGnfpZoF6RkkWI1CKE8oys-M>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] Requirement for Intermediaries to Update Session ID for other parties
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2016 19:20:13 -0000

Brett,

Thanks for the reply. I have some comments / questions inline. I’m not trying to be argumentative in my comments - I really just want to make sure we have a strong argument for SHOULD so really just want to make sure these reasons are valid.


> 
> 
> 1) A proxy can't really do it.
> 

Would a proxy ever do anything that would require it do to it? A proxy will just be forwarding messages back and forth for the most part.


> 2) I assume proxy B2BUA's that only initiate BYE's would not want to do it
> except when sending BYE.
> 

Why would they “not want to”?


> 3) Because it causes extra traffic and potential for glare, the
> administrator might not want the extra messaging to occur solely to update
> the UUID.
> 


The potential for glare is a potentially good argument, but is “extra messaging” really an issue?


> 4) The request might not reach the device that the intermediary is
> attempting to update.  Thus, it could be completely useless extra traffic.
> 


This doesn’t seem like a good reason not to try to update.


> 5) Methods that the intermediary is willing to use for the update might not
> be within the received Allow header.
> 


This is a good one, although I would think re-INVITE is always available (or whatever is being used for session refresh), so is there really ever a case where there is no way to do it? I noticed you said “willing to use” which I’m sure you did intentionally. That doesn’t mean there is no way, but if there was a requirement, then they would have to.


> 6) It can cause the intermediary to be part of an infinite change loop
> unless use re-INVITE without offer.
> 

Simplest way to update would be whatever message is being used for session refresh. That should not cause problems.


> 7) The intermediary might not have auth credentials to allow the change to
> be successful.
> 


How would this happen?


> 8) Because of race conditions and other things, the intermediary initiated
> messaging intended to correct the UUID could cause other locations to switch
> to an incorrect value.


Why would this happen?