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

[Brett Tate <[e-mail]>]

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"