Subject: [Insipid] draft-ietf-insipid-session-id-18: comments and questions

From: Brett Tate <[email-masked]>
Date: Wed, 23 Mar 2016 12:31:10 -0400

Hi,

Sorry about the delay.

The following are some comments and questions concerning
draft-ietf-insipid-session-id-18.

Thanks,
Brett

------

1) Section 2 paragraph 3:  To remove compliance ambiguity (e.g. if section
6 or 7 must be followed), please add something like the following to the
paragraph: The "endpoint" definition's "generally located" exclusion
allows intermediaries to originate and terminate SIP messages without an
endpoint being part of the session or transaction.

2) Section 6 paragraph 2 and bullet 1: The text is vague concerning if the
"MUST NOT change" only applies to the endpoint originating the request.

3) Section 6 paragraph 6 and section 7 last paragraph: If not intentional,
"must" is lowercase.

4) Section 6 paragraph 6: CANCEL usage isn't limited to INVITE requests.
Thus potentially should reword so that it applies to the transaction being
cancelled.

5) Section 6 paragraph 8: Should something similar to this paragraph be
added to section 7?  For instance, it is currently ambiguous if section 7
paragraph 6, section 7 paragraph 12, or something else applies if
intermediary receives message without Session-ID when there are cached
values for the dialogs.  One aspect of the ambiguity is contained within
comment 14.

6) Section 7 paragraph 10: CANCEL usage isn't limited to INVITE requests.
Thus potentially should reword so that it applies to the transaction being
cancelled.

7) Section 7 last paragraph: Append something like the following: "if they
maintain knowledge of the session identifier".

8) Section 8: Concerning paragraph 1 statement "To ensure that all
endpoints and intermediaries involved in a session agree upon the current
session identifier", following the process does not guarantee it.  There
is too much potential for race conditions to guarantee it (e.g. see RFC
6141 section 4.8).  Please add a statement within this section to indicate
that following this document does not provide a way to ensure that all
endpoints and intermediaries involved in a session will agree upon the
current session identifier.

9) Section 8 bullets: Concerning the MUST 'include this new UUID as the
"remote" parameter for any subsequent messages' statements, it isn't clear
concerning the impacts when an intermediary relays a received Session-ID.
For instance, are the bullets indicating that the intermediary MUST fix
the remote UUID when relaying requests/responses?  I think that they
should be reworded or a paragraph added to help interpret the bullets.

10) Section 8 bullet 1: As I mentioned within 1/6/2016 email (linked
below), I'd prefer CANCEL and its response not be able to update the
session identifier.  Does anyone know the precise timing concerning when
481 should be sent for late CANCEL?  For instance, it looks like RFC 6026
Timer L means that a device should still return 200 for CANCEL up to 64*T1
after having sent 2xx for INVITE (even if already received ACK).  This
would mean that a CANCEL can be 64*T1 seconds late and cause a session
identifier change.  The behavior appears to be similar within 3xx-6xx
response to INVITE situation; however the default timer to forget the
transaction appears to be smaller and I'm not sure what should occur for
late CANCEL if return 2xx.  Allowing CANCEL to update things also appears
to conflict with RFC 6141 section 3.3 "SHOULD return 2xx" since the
desired impact of CANCEL is to cause a 487 response for the cancelled
transaction (which appears would undo the CANCEL changes).

http://www.ietf.org/mail-archive/web/insipid/current/msg01085.html

11) Section 8 bullet 2: In my opinion, 3xx (for instance 305) should be
handled like 4xx-6xx.  If the 305 was generated for security/overload
reasons, it seems like an exposure to comply with the bullet's mandate.
However since mid-dialog 3xx isn't well defined (mentioned within RFC
5057), I don't have a strong opinion on the topic.

12) Section 8 bullet 3: Clarify the last sentence since unsure what
"latest UUID value" means: stored UUID or request's UUID.

13) Section 8 bullet 4: Concerning ACK for 3xx, I have the same comment as
bullet 2.

14) Section 8 bullet 5: Allowing failure responses to update the cached
UUID is a little odd (although it provides a value for ACK).  It can
potentially cause a disagreement concerning session identifier.  Unless
clarify within the draft, it also adds ambiguity when attempting multiple
mid-dialog locations per RFC 3263.

If there were multiple failure responses causing resubmit with higher
cseq, the last change is cached on intermediary.  If session identifier is
subsequently missing from 2xx response (or other final response), the
intermediary will have a cached UUID which does not get relayed to the
endpoint (except maybe when section 7 paragraph 12 is applicable).

Concerning devices that attempt multiple mid-dialog locations per RFC
3263, I guess that they will decide how to correlate potentially
conflicting values associated with multiple responses (such as 503, 482,
and other response or timeout) since they can select a specific branch to
honor similar to if outside of dialog.  Their decision might conflict with
how other intermediaries which saw the responses might interpret what
should be the current session identifier.  Concerning re-INVITE, I'm not
really sure what remote UUID to include within the ACKs of non-winning
branches.  For instance if receive 2xx for branch A and then receive 503
for branch B (i.e. both requests sent before 2xx received), branch A is
obviously the desired winner.  Should the late 503 cause an update of the
stored UUID?  If not, should remote UUID within ACK reflect 503's value or
stored UUID?

---

From: Paul Giralt (pgiralt) <[email-masked]>
Date: Wed, 23 Mar 2016 23:09:40 -0400

Brett, 

Thanks again for the detailed review. See inline… 

> On Mar 23, 2016, at 12:31 PM, Brett Tate <[email-masked]> wrote:

> endpoint being part of the session or transaction.

I’ve added the following at the end of the paragraph: 

"In certain scenarios, intermediaries are allowed to originate and terminate SIP messages without an endpoint being part of the session or transaction."

> "MUST NOT change" only applies to the endpoint originating the request.

I think it’s clear that it’s talking about the endpoint that allocates the UUID value (which presumably is the one originating the request), but in the interest of clarity, I’ll change the sentence to: 

"Once an endpoint allocates a UUID value for a communication session, the endpoint originating the request MUST NOT change that UUID value for the duration of the session"

> 3) Section 6 paragraph 6 and section 7 last paragraph: If not intentional,

It was actually intentional, but looking at it again, doesn’t hurt to make it capitalized. Fixed.

> Thus potentially should reword so that it applies to the transaction being

Assuming you meant paragraph 7. Changed “the original INVITE” to “the original request” 

> values for the dialogs.  One aspect of the ambiguity is contained within

Yes, I think similar verbiage is needed. I will distinguish between receiving a message without Session-ID where one has never been received before as opposed to when one has already been previously received. Modified text and added a new paragraph: 

     If an intermediary receives a SIP message without a Session-ID header field 
     or valid header field value from an endpoint for which the intermediary is not 
     storing a "remote-uuid" value, the intermediary MAY  assign a "local-uuid" value 
     to represent that endpoint and, having done so, MUST insert that assigned value 
     into all signaling messages on behalf of the endpoint for that dialog.  In effect, 
     the intermediary becomes dialog stateful and it MUST follow the endpoint procedures 
     in Section 6 with respect to Session-ID header field value treatment with itself 
     acting as the endpoint (for the purposes of the Session-ID header field) for which 
     it inserted a component into the Session-ID header field value.  If the intermediary 
     is aware of the UUID value that identifies the endpoint to which a message is 
     directed, it MUST insert that UUID value into the Session-ID header field value as 
     the "remote-uuid" value.  If the intermediary is unaware of the UUID value that 
     identifies the receiving endpoint, it MUST use the null UUID value as the 
     "remote-uuid" value.
     
     If an intermediary receives a SIP message without a Session-ID header field 
     or valid header field value from an endpoint for which the intermediary has 
     previously received a Session-ID and is storing a "remote-uuid" value for that 
     endpoint, the lack of a Session-ID MUST have no effect on what the intermediary 
     believes is the UUID value of the endpoint.  That is, the intermediary MUST NOT 
     change the internally maintained "remote-uuid" value for the peer.

> Thus potentially should reword so that it applies to the transaction being

Changed “the corresponding INVITE” to “the corresponding request” 

> maintain knowledge of the session identifier”.

Good callout. Done. 

> current session identifier.

Totally agree and I avoided using the word “guarantee” for the specific reason you outline, but I guess “ensure” might be too strong as well. How’s this? 

     Both endpoints and intermediaries MUST assume that the UUID value of the 
     session peer MAY change at any time due to service interactions.  It is desirable
     to have all endpoints and intermediaries involved in a session agree upon the 
     current session identifier when these changes occur. Due to race conditions or
     certain interworking scenarios, it is not always possible to guarantee session 
     identifier consistency; however, in an attempt to ensure the highest likelihood
     of consistency, all endpoints and intermediaries involved in a session MUST 

> should be reworded or a paragraph added to help interpret the bullets.

I took this a step further and added text stipulating that an intermediary that accepts a new UUID SHOULD communicate this new UUID to other endpoints involved in the session to help prevent this problem from happening in the first place. 

I’m not sure what the best approach here is, but I’m inclined to say that the intermediary MUST fix the remote UUID when relaying a request / response although I’d be okay with a SHOULD. Do you have any opinion? 

> http://www.ietf.org/mail-archive/web/insipid/current/msg01085.html

I’m trying to think if there is any downside to disallowing CANCEL from modifying the stored value. At first glance, I can’t think of any downside. Typically a CANCEL will result in a 487 which already results in the value not being stored, so the only case where disallowing CANCEL from modifying the stored value would actually make a material change would be in the 2xx for CANCEL case. Even then, because CANCEL is not end-to-end and it must be identical to what was in the INVITE, it probably does not make sense to store the value from the CANCEL. I’ve added an additional bullet to Section 8: 

       <t>As stated in Section 6 and Section 7, the Session-ID header field value 
       included in a CANCEL request MUST be identical to the Session-ID header field 
       value included in the corresponding INVITE. Upon receiving a CANCEL request, 
       an endpoint or intermediary would normally send a 487 response which, by the
       rules outlined above, would result in the endpoint or intermediary not storing
       any UUID value contained in the CANCEL. Section 3.8 of 
       <xref target="RFC6141"></xref> specifies conditions where a CANCEL can result 
       in 2xx response. Because CANCEL is not passed not end-to-end and will always
       contain the UUID from the original INVITE, retaining a new UUID value received 
       in a CANCEL may result in inconsistency with the Session-ID value stored on 
       the endpoints and intermediaries involved in the session. To avoid this situation, 
       an endpoint or intermediary MUST NOT accept the new UUID value received in a 
       CANCEL and any subsequent messages MUST contain the previously stored UUID value 
       in the "remote" parameter".</t>

> 5057), I don't have a strong opinion on the topic.

I’m inclined to leave it as-is, especially because mid-dialog changes resulting in a 3xx are almost non-existent. 

> "latest UUID value" means: stored UUID or request's UUID.

It means the request’s UUID. Fixed. 

> 13) Section 8 bullet 4: Concerning ACK for 3xx, I have the same comment as

Also inclined to leave as-is for the same reasons as above. 

> potentially cause a disagreement concerning session identifier.  

I think the value changing in a failure response is in itself an unlikely scenario to begin with and this scenario is not likely to occur. 

As you mentioned, without updating the UUID on a failure response, we don’t have a value for ACK. Having the value in the ACK outweighs any potential out of sync that may occur in a rare scenario where the UUID changes on a failure response. I’m inclined to leave as-is. 

> Unless

I’m not understanding why the 2xx would suddenly be missing the session identifier in this case. I already addressed this case above to ensure that a missing session identifier when one was present in previous messages does not overwrite. Does this address your concern here? 

> stored UUID?  If not, should remote UUID within ACK reflect 503's value or

When multiple locations are attempted, wouldn’t they be attempted in series? I would think that the 503 would actually come back before the request that leads to the 2xx if the session establishment really does succeed. If the 503 never made it to the far-end endpoint and this is really traversing proxies, I’m guessing the 503 will likely come back without a session identifier anyway, which would not cause a problem. I’m struggling to find a real-world case where something like this would happen that would realistically cause a problem with the current draft. 

To answer your specific questions - if it really did play out the way you outlined above and the 503 does include a session identifier (and it happens to be different than the one in the 2xx), then yes, the 503 should cause an update and the remote UUID in the ACK for the 503 would reflect the 503’s value (which would also now be the stored value because we accept stored values from the 503). Not ideal, but this scenario does not seem realistic to me. Please correct me if I’m missing something. 

Thanks again for all your feedback. Please let me know your thoughts so we can try to drive this to WGLC. 

Thanks 
-Paul

---

From: Paul Giralt (pgiralt) <[email-masked]>
Date: Wed, 23 Mar 2016 23:10:37 -0400

Brett, 

     

Good callout. Done. 

Thanks 
-Paul