Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 05 Feb 2015 00:15:14 +0000

Brett,

Sorry for the belated reply.  I wasn't ignoring your message, but wasn't 
sure what to do.  I'm still not sure what to do, so let's try to come up 
with some agreeable text.

>>  If it is answering on behalf of a remote endpoint and knows
>>  what the "Session-ID" header value is, it should include
>>  that value.
>>
>>  If it does not know (e.g., the remote endpoint has never
>>  sent one), I think it should follow the same logic we
>>  describe for provisional responses. What if we make this
>>  change:
>>
>>  "When an intermediary transmits a provisional
>>  response >>or a response to a CANCEL request<<, ..."
>
>I don't think that it is adequate.
>
>>  Are there other such cases?
>
>A B2BUA can generate requests and responses on behalf of both sides. In 
>my
>opinion, section 7 covers some individual situations; however, it 
>appears to
>be missing the general case of tracking remote/local UUIDs and then 
>using
>the UUIDs when generating (instead of relaying) subsequent requests and
>responses associated with the "session".

This is largely purposeful.  We do not want intermediaries really 
getting involved in the exchange of UUID values.  The instances where 
they do (e.g., 3PCC), then they are forced to do that, since they will 
potentially be originating UUID values.  If an intermediary is 
responding on behalf of an endpoint, then what the text currently says 
that "if it knows" the UUID value of the opposite endpoint, includes it. 
  Otherwise, it either uses the NULL value or fabricates a value.

In what way would you like to see the text re-worded, keeping in mind 
that we want B2BUAs to take a hands-off approach as much as possible.

>>  >That is the issue. The UPDATE changed the UUID so it
>>  >no longer matches the value sent within prior INVITE
>>  >and subsequent CANCEL. Thus I'm trying to determining
>>  >which remote UUID that the B2BUA should or must include
>>  >within the CANCEL's 2xx, INVITE's 487 response, and
>>  >non-2xx's ACK when the To tags reflect that same dialog
>>  >that was updated.
>>
>>  Perhaps I need a picture. Can you tell me again why the
>>  UPDATE would change the UUIDs?
>
>>From an intermediary perspective, it is irrelevant why something on 
>>each
>side decided to change the supplied UUID. My understanding is that the
>draft requires (or will require) the intermediary to track the change 
>so
>that it MAY/SHOULD/MUST be used when the intermediary generates 
>(instead of
>relays) subsequent requests and responses associated with the 
>"session".

That would be true of intermediaries like PBXes that are switching calls 
from one leg to another. It's only in situations where the intermediary 
is going to do something that causes endpoints to have the wrong value 
that they need to ensure they convey the right value.  If the SBC is not 
in the business of switching call legs from one device to another like a 
PBX does, it would not have to maintain this state at all.

That said, there is nothing to prevent an SBC from being more 
intelligent and maintaining these values.  It might be good, so long as 
it doesn't block or change them.

>Concerning "why the UPDATE would change the UUIDs" ... as mentioned 
>within
>http://www.ietf.org/mail-archive/web/insipid/current/msg00993.html, a 
>B2BUA
>interaction occurred which replaced a user or user's device on one
>side while call setup was occurring on the other side.
>
>The picture is the trapezoid model with B2BUAs instead of proxies (i.e.
>caller, B2BUA1, B2BUA2, called) with potential forking and replacements
>(i.e. "session" changes for a particular dialog). The B2BUAs generate 
>487
>instead of relaying them.

I guess I'm still missing something.  If a B2BUA exhanges Bob with Carol 
(Alice remains the constant "other endpoint"), then the B2BUA might send 
an INVITE to Carol and connect her to Alice.  This would be like Section 
9.3, where at the end Alice and Carol have different end-to-end values.  
This is a situation where a "nice" B2BUA might send a re-INVITE to Alice 
to inform Alice of the change in UUID values.  This would require such a 
B2BUA to be stateful and keep track of these UUID values.

Or is this another flow?  I'm happy to modify the flows or add text, but 
I'm not sure what you want to add where.  Can you tell me exactly what 
changes you'd like to see?  (Note I modified 9.3 as you can see in the 
exchange with Paul K.)

>>  >> Is this just a repeat of the previous?
>>  >
>>  >Almost; the distinction is that the CANCEL is sent
>>  >within dialog (i.e. cancelling a re-INVITE).
>>
>>  There should be no difference in the UUID values uses
>>  with either in-dialog or OOD, as it's sent in relation
>>  to the "session".
>
>The "session" changed. Consider hypothetical that B2BUA received INVITE
>outside of dialog with {A, N}. Forking during call setup resulted in 
>{A, B}
>and {A, C}. Because of services while still inviting (and messages sent
>over early dialog), the Session-IDs became {X, B} and {Y, C}. If the 
>CANCEL
>with {A, N} was received out of dialog, what should be the Session-ID 
>of
>CANCEL's 200 and INVITE's 487 if sent with To tag reflecting dialog of 
>{X,
>B}? If B2BUA then sent CANCEL and the subsequently received 487 (for
>INVITE) indicated {C, whatever} with To tag of {Y, C} dialog, what 
>should be
>the Session-ID of the 487's ACK? I assume "whatever" is irrelevant; 
>however
>I'm not sure if (and why) ACK's local UUID should be A or Y.

I think I see your point on expanding this sentence:

"When an intermediary transmits a provisional response or a response to 
a CANCEL request, the “remote-uuid” field will contain the UUID value of 
the UA that sent the message that prompted the transmission of the 
provisional response."

Maybe it should be broader:

"When an intermediary transmits a response on behalf of a remote 
endpoint, including a provisional response or a response to a CANCEL 
request, the “remote-uuid” field will contain the UUID value of the UA 
that sent the message that prompted the transmission of the provisional 
response."

The rest of that paragraph goes on to explain that the "local-uuid" 
value will be the remote UA's UUID or "null".

Feel free to re-word the above and I'll insert it into the text :-)

>>  In the event that a UUID value changed (which should
>>  only be because an actual endpoint somewhere downstream
>>  changed to another endpoint), that new UUID value should
>>  be used going forward. So if some intermediary device
>>  sees this:
>>
>>  {A.B} -->
>>    <-- {B,A}
>>
>>  And then some new message comes through with a new value
>>  for A (and quite possibly B) as follows:
>>  {C,F} -->
>>
>>  If it is going to be responding to messages and use the
>>  Session ID values, it should immediately take note of
>>  {C,F} coming from the left side.
>
>I get that; however then CANCEL received outside of dialog indicated 
>{A, B}.
>If the B2BUA subsequently generates ACK to the called party over what 
>is/was
>{C, F}, should the Session-ID be {A, F} or {C, F} (assuming received 
>487
>indicated "F")?

Whatever value is received in the "local-uuid" field gets copied into 
the "remote-uuid" field when responding.  So, one of the {A,B} values we 
know exactly what to do with.

The B2BUA could just put the received "remote-uuid" value into the 
tranmitted "local-uuid" field, blinding assuming the endpoint knew the 
right value.  That's what I would do, stick with the idea the B2BUA is 
relatively dumb about UUIDs.  However, the B2BUA could insert a 
different value for the "local-uuid" per the spec, including the null 
value OR the actual UUID of the remote endpoint if it knew it. However, 
I think that's asking the B2BUA to maintain too much intelligence.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Feb 2015 12:36:06 -0500

>> From an intermediary perspective, it is irrelevant why something on each
>> draft requires (or will require) the intermediary to track the change so
>> relays) subsequent requests and responses associated with the "session".
>

I think *most* B2BUAs will sometimes need to originate messages. E.g.,
- send a BYE to terminate a session by policy
- send a session timer refresh.

Any B2BUA that will ever originate a message needs to maintain this state.

	Thanks,
	Paul K

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Feb 2015 13:46:56 -0500

Hi,

Thanks for the response; reply is inline.

> >A B2BUA can generate requests and responses on behalf of
> >both sides. In my opinion, section 7 covers some individual
> >situations; however, it appears to be missing the general
> >case of tracking remote/local UUIDs and then using the UUIDs
> >when generating (instead of relaying) subsequent requests
> >and responses associated with the "session".
>
> This is largely purposeful.  We do not want intermediaries
> really getting involved in the exchange of UUID values.

Sounds great to me.  If that is really true, add something like the
following paragraph to section 7.

"Intermediaries MAY track the Session Identifier values associated with a
transaction and dialog.  However since it is NOT REQUIRED (and because of
other reasons), they MAY provide inaccurate Session-ID values when
generating related requests and responses."

> If an intermediary is responding on behalf of an endpoint,
> then what the text currently says that "if it knows" the
> UUID value of the opposite endpoint, includes it.  Otherwise,
> it either uses the NULL value or fabricates a value.

What section and paragraph says that?

> In what way would you like to see the text re-worded, keeping
> in mind that we want B2BUAs to take a hands-off approach as
> much as possible.

Sounds great to me.  If the draft is clear about that (such as by adding the
mentioned paragraph), I'll quit being concerned about the race conditions,
CANCEL, et cetera which will make it impossible (when mid-dialog Session-ID
changes occur) for intermediaries to know the correct Session-ID values for
use when subsequently generating (instead of relaying) requests and
responses.  Endpoints have the ambiguity issue; however at least one of the
UUIDs would be accurate.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 09 Feb 2015 22:43:20 +0000

Brett,

>generating related requests and responses."

OK, how about these as the first two paragraphs?

=====
The Call-ID often reveals personal, device, domain or other sensitive 
information associated with a user, which is why intermediaries, such as 
session border controllers, sometimes alter the Call-ID. In order to 
ensure the integrity of the end-to-end Session Identifier, it is 
constructed in a way which does not reveal such information, removing 
the need for intermediaries to alter it.

Intermediaries MAY track the Session Identifier values associated with a 
transaction and dialog. However, since it is generally NOT REQUIRED (and 
because of other reasons), they might provide inaccurate Session-ID 
values when generating related requests and responses. As such, 
intermediaries MUST NOT alter the UUID values found in the Session-ID 
header, except as described in this section.
=====
Note I changed a MAY in your document to "might".  I don't want to 
suggest that it's permissible, but noting that it might happen is 
acceptable.

And the rest of the whole section is really intended to very tightly 
limit the times wherein an intermediary might manipulate the values.

>What section and paragraph says that?

That's in Section 7.  Just to avoid mismatch in paragraph count, the 
text is:

====
When an intermediary transmits a provisional response or a response to a 
CANCEL request, the “remote-uuid” field will contain the UUID value of 
the UA that sent the message that prompted the transmission of the 
response. When the UUID of the destination UA for the message that 
prompted the transmission of the response is known, the intermediary 
MUST insert the UUID of the destination UA in the “local-uuid” field of 
the response. Otherwise, the intermediary MAY set the “local-uuid” field 
of the response to a locally generated UUID value or the null UUID 
value.
====

Note that the bit about CANCEL is new and added per our discussion.  The 
word "provisional" was removed from the original text, also, to account 
for the CANCEL response.

>responses. Endpoints have the ambiguity issue; however at least one of 

The section in intermediaries started out by limiting when they were 
allowed to touch messages.  The intent was to strictly reduce 
opportunity to do damage, while being mindful that some will.

The one piece of text that is missing is a statement that says something 
like this as a final paragraph in section 7:

====
Having said the foregoing, intermediaries that manipulate messages 
containing Session-ID header values should be aware of what values were 
last received by an endpoint and, following any kind of service 
interaction initiated or affected by the intermediary, of what values 
the receiving endpoint should have knowledge to ensure that both 
endpoints in the session have the correct and same values.  If an 
intermediary can determine that an endpoint might not have received a 
current, correct Session-ID header value, the Intermediary SHOULD 
attempt to provide the correct Session-ID header value to the endpoint 
such as by sending a re-INVITE message.
====

How does that sound?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 09 Feb 2015 23:00:30 +0000

Paul,

>Any B2BUA that will ever originate a message needs to maintain this 

Fair point, though this is not really altering a value -- which is what 
most of Section 7 deals with.  In this case, it would be just using 
known values to initiate messages.

But, I don't think we speak about that.  Want to suggest a blurb to say?

Maybe some "Finally, " text at the end (after that "Having said the 
foregoing," paragraph I proposed to Brett) like this:

====
Finally, intermediaries compliant with this specification that initiate 
messages not in response to having received a message from a remote 
endpoint, such as sending a BYE to terminate a dialog, MUST ensure that 
the proper Session-ID value is conveyed in that message.  If the UUID of 
the remote endpoint is known, that value MUST be used as the 
"local-uuid" value of the transmitted message.  If the UUID of the 
remote endpoint is unknown, then the intermediary MUST use either the 
null UUID (preferred) or fabricate a UUID to populate the "local-uuid" 
field.  Likewise, if the UUID of the receiving endpoint is known, that 
value must be included in the "remote-uuid" field.  If the UUID of the 
receiving endpoint is unknown, the "remote-uuid" field must be set to 
null UUID.
====

Thoughts?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 09 Feb 2015 23:00:30 +0000

Paul,

====

Thoughts?

Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Feb 2015 10:00:59 -0500

Hi,

> OK, how about these as the first two paragraphs?

<snip>

> Note I changed a MAY in your document to "might".  I don't
> want to suggest that it's permissible, but noting that it
> might happen is acceptable.

If it is not permissible, then intermediaries which generate (instead of
only relay) requests and responses must track the Session-ID.  You can
remove my suggested paragraph since I only proposed it because you indicated
"We do not want intermediaries really getting involved in the exchange of
UUID values".

Consider the following race condition where the UPDATEs cross between A and
the proxy.  If the proxy generates a 407, SHOULD/MUST it indicate {C,A},
{B,A}, or something else?  What draft snippet supports your answer?

A   proxy

-->  UPDATE {A,B}
<-- UPDATE {C,A}
<-- 407 {?,A}

Do you think intermediaries which generate (instead of relay) requests such
as BYE SHOULD/MAY/MUST track the Session-ID UUIDs so that the BYE could
contain the same UUIDs within the Session-ID?  If so, where is it mentioned
within the draft.

> word "provisional" was removed from the original text, also, to account

Same comment as last time, I don't think that it is adequate.  It looks like
the paragraph only applies to CANCEL responses and provisional responses.
What about all of the other requests and responses that an intermediate can
originate?

> opportunity to do damage, while being mindful that some will.

Damage?  Because of all the potential race conditions, the draft provides no
means to ensure that an endpoint knows the correct remote-uuid.

If A receives the following at about the same time, does A "know" that the
remote-uuid is B or C?  A can only assume that they were sent in the order
received.

200 response with {B,A}
UPDATE with {C,A}

> such as by sending a re-INVITE message.

I guess that you changed your mind about if an intermediary should ever send
a request solely to update the Session-ID.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Feb 2015 17:23:25 -0500

> known values to initiate messages.

The point is that such devices must keep state remembering the values to 
use.

> receiving endpoint is unknown, the "remote-uuid" field must be set to

I think that almost works, depending on what "is known" means.
A box that doesn't maintain state about the last values used could be 
considered to "not know" the values when sending a new message.
Also, from the perspective of the intermediary, both of the endpoints 
are "remote endpoints".

If the intermediary is between Alice and Bob, and it has seen a message 
containing {A,B}, then when originating a message toward Bob it should 
include {A,B}, and when originating a message toward Alice it should use 
{B,A}.

But I think *saying* that in a clear way is going to require more text.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 Feb 2015 13:25:30 +0000

Brette,

>"We do not want intermediaries really getting involved in the exchange 

Ideally, SBCs would leave these values alone.  There are cases where 
SBCs might autonomously generate messages (as Paul K pointed out), so 
saying something about tracking these values is OK.  The text with your 
addition says the value might be tracked, but generally the SBC should 
not alter the UUIDs.  Perhaps this tweak helps?

"Intermediaries MAY track the Session Identifier values associated with 
a transaction and dialog.  However, since it is generally NOT REQUIRED 
and because of other reasons, they might provide inaccurate Session-ID 
values when generating related requests and responses.  As a general 
rule, intermediaries MUST NOT alter the UUID values found in the 
Session-ID header, except as described in this section.  When 
autonomously originating a message, an intermediary MAY insert a tracked 
UUID value, or the “null” UUID or a locally generated UUID (in the case 
that there is no known UUID for the peer UA), or not include the 
Session-ID header at all to avoid miscommunicating an incorrect UUID 
value."

>contain the same UUIDs within the Session-ID? If so, where is it 

I don't want to require them to track.  I would be OK if they inserted 
the "null" UUID when they do not know a vlaue.

As for the above exchange, why would a 407 be sent in response to an 
UPDATE?  Wouldn't that be sent perhaps on an initial INVITE?  In any 
case, I would expect the SBC (if it tracks UUID values) to send {C,A} 
since it knows that C is on the right side.

>What about all of the other requests and responses that an intermediate 

OK, how about this re-wording:

"When an intermediary originates a request or response, such as a 
provisional response or a response to a CANCEL request, or a BYE 
message, the “remote-uuid” field will contain the UUID value of the 
receiving UA .  When the UUID of the other peer UA is known, the 
intermediary MUST insert the UUID of the peer UA in the “local-uuid” 
field of the message.  Otherwise, the intermediary MAY set the 
“local-uuid” field of the message to a locally generated UUID value or 
the null UUID value."

>means to ensure that an endpoint knows the correct remote-uuid.

With standard signaling, there are no race conditions that cause a 
problem.  The only scenario wherein UUIDs might not be properly 
understood is when there is some kind of non-standard service 
interaction.  There are also issues if the SBC decides to try to be 
somewhat smart and reflect UUIDs and set the "local-uuid" to NULL in 
some provisional response message.  For a period of time, {A,B} might be 
changed to {A,null} in A.  It might be best for SBCs to not include a 
Session-ID header if it cannot fill in values properly.  (Any SBC that 
does not implement this spec would do that.)  I tried to address that in 
the above text I quoted: best to just not include the header if the 
right values cannot be provided.

>remote-uuid is B or C? A can only assume that they were sent in the 

It should know.  If the endpoint cannot determine its current state, we 
have a larger issue.  It should know from the CSeq value or state 
transition which message is newer.

>a request solely to update the Session-ID.

Yeah.  With standard signaling, this won't be an issue.  But, if an SBC 
is going to do something proprietary to join together call legs, I 
suppose it should take the extra step to ensure that the UUID values are 
right.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 Feb 2015 16:08:32 +0000

Paul,

>The point is that such devices must keep state remembering the values 
>to use.

Understood.

>include {A,B}, and when originating a message toward Alice it should 
>use {B,A}.
>
>a

Your request and one of Brett's is the same.  In trying to enhance the 
paragraph related to tracking UUID values, maybe we have it covered.  
So, let's remove the last paragraph I propose above and have this as the 
first two paragraphs of Section 7:

transaction and dialog.  However, since it is generally NOT REQUIRED and 
because of other reasons, they might provide inaccurate Session-ID 

Paul