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

Brett Tate <brett@broadsoft.com> Tue, 14 June 2016 18:08 UTC

Return-Path: <brett@broadsoft.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 C49E512D880 for <insipid@ietfa.amsl.com>; Tue, 14 Jun 2016 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dTpaGQbxR7R for <insipid@ietfa.amsl.com>; Tue, 14 Jun 2016 11:08:31 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 338D412D881 for <insipid@ietf.org>; Tue, 14 Jun 2016 11:08:31 -0700 (PDT)
Received: by mail-qg0-x22c.google.com with SMTP id l44so88602874qgd.0 for <insipid@ietf.org>; Tue, 14 Jun 2016 11:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to :content-transfer-encoding; bh=ypYilOZk9WRiRt90+b/iZfrSGlDnOstuJASyS8vhiuY=; b=2CnenrHO6CbE7H0Sg76HPOv+H+KjT38qWttwqOkIeDeQlVszwamoBH65f0t7DP6eiI k7gxA1gZGwWnb4ygC6IwYZQNCQcrr0gyMuigYqQmeB/MfYtsQBPKP2Q3zRQIEAfgq6Z9 DeraZj06wp4KFkJPN3MySiEM4Ww71KjGI/ed4bk6wPVSj1/nbuEs7jvpA3AqAePPMeID uiDgr8Wz++sCUcZgqPbr3NAKPWRaPcXdEe6P4BUNF2qyM2TIo2ypT7U3QpPwXeM3xmqM /4NN/6mMj6UrEjraFpekF2H6t35jGuQ81Hr2wwFLry6RRAT8XFzu9qY9GXaBXkCGcuCr P5Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-transfer-encoding; bh=ypYilOZk9WRiRt90+b/iZfrSGlDnOstuJASyS8vhiuY=; b=F6XHQ9DfO4YR9ri18hH01aGH5WV4sjyVi+NW2jBYVpXRk0zvqKpiuiXfdtNGzs2Oxa phBt+lr4GuqXosvmgtWb2RW6R9HRHUlEOprp2pdj1fNyLXfNaZbO1aiYxRykacIRB5pP ZOZ5rDTJ1itjHou/TWEQ1hwLies1QJwDGholq4Ltkyo5mWajKYCw91JCYQLEiTVAno1e 9dK2lwtWO7eJul0aROpQH785Q6MJpC8vACqB77DP4remE1Tvzb1qC/nGcoepLJWv9vmF UCj9+2N+4xzioNNX9LnY5HgHEaJNzfLrZP+iFos0f+t+EAE7PO73FfvXDb2IaTx6Gnmb ZMng==
X-Gm-Message-State: ALyK8tIS+ihT58QeflgYa2egSba9dY177mfCgzQdB868RRbCcCKWyBgHmmse1lrFt/XLeKriHzQfNn2s+VMdgHsS
X-Received: by 10.140.25.150 with SMTP id 22mr21077325qgt.34.1465927710093; Tue, 14 Jun 2016 11:08:30 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdHGZih5BiX31+N4TFqkNYiQW61mjw==
Date: Tue, 14 Jun 2016 14:08:29 -0400
Message-ID: <8caee4daa818f23c867a1bc7a742c063@mail.gmail.com>
To: insipid@ietf.org, "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/ysW5e__oNUGClPHrGvarQg-Uunc>
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, 14 Jun 2016 18:08:33 -0000

Hi,

Reply is inline.

> > 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.

Concerning "ever do", the draft indicates "If an intermediary can
determine".  However, I'll assume that the draft isn't mandating a proxy to
morph into a B2BUA to satisfy the SHOULD (or proposed MUST).


> > 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”?

Depending upon interpretation, it might require them to remain a B2BUA
longer than their current preference.  To avoid some of the impacts of
B2BUAs, some proxy B2BUAs want to act as proxy until (if ever) required to
morph into a B2BUA to release the call.  However, I'll assume that the draft
isn't mandating a proxy to morph into a B2BUA to satisfy the SHOULD (or
proposed MUST) even though it might morph later for another reason.


> > 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?

If administrator disables compliance with the proposed mandate, I assume
that it wouldn't be because of "extra messaging" unless a highly involved
intermediary has a bug which causes the administrator controlled
intermediary to need to frequently initiate messaging to update the UUID.


> > 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.

Concerning the proposed mandate, how many tries are mandated within a
session before a compliant intermediary can give up?


> > 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.

I mentioned "willing to use" for two reasons.  One reason was because they
need to pick their poison; potential re-INVITE glare or potential change
loop.  The other reason is that the intermediary might not want to start
updating things while there is an outstanding request associated with the
session.


> > 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.

If receive new UUID within response, you need to update other side; if you
receive new UUID within response, you need to update other side; repeat;
repeat; ...


> > 7) The intermediary might not have auth credentials
> > to allow the change to be successful.
>
> How would this happen?

Not all intermediaries have auth credentials to act as both endpoints within
the session.

Speaking of authentication, what is the proposed mandate concerning ACK for
failed authentication?  It sounds like the proposal could force a compliant
device to initiate additional messaging if the attacker supplies different
remote UUID within the ACK (i.e. intermediary notices that attacker's side
is not using the current/correct UUID).


> > 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?

"Because of race conditions and other things"