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

["Paul E. Jones" <[e-mail]>]

Brette,



>Hi,
>
>Thanks for the response; reply is inline.
>
>>  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".

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



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

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.


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

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


>
>
>>  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.
>
>Damage? Because of all the potential race conditions, the draft 
>provides no
>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.


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

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.


>>  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?
>
>I guess that you changed your mind about if an intermediary should ever 
>send
>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