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

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

Brett,

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

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.


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


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

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