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

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

Brett,

I went back and looked at the intermediary text section again.   I think 
with the last revision, some of the paragraphs were becoming repetitive. 
  I also think that in addressing the handling of provisional responses 
and responses to CANCEL, we were overloading that paragraph too much by 
trying to also handle origination of messages like BYE.  So, I split 
that into two paragraphs.

The "must not alter" text was removed in the process, so I'm not sure if 
that addresses your concerns about a race condition or not.  I didn't 
fully understand that, so feel free to raise the point again on the new 
"March 5th Edition". ;-)

On the point of not meeting "Requirement 1", I think if the intermediary 
originates a message and is ignorant of the Session-ID values, yes.  
However, we cannot require intermediaries to add this additional state.  
I guess we could, but I don't think folks would like to have that pushed 
on them.  So, I added a new first paragraph to the intermediaries 
section.  With that in place, we could then put additional rules in 
place if you feel we might be violating a rule.  And, one might argue 
that we are in the origination of the BYE message ("When an intermediary 
originates a request message ..." paragraph).  I personally think it's 
OK if an intermediary generates a message that did not come from a UA 
that the "null" UUID value be inserted if the intermediary doesn't want 
to maintain this state.

You said, "Inserting "null" could impact the next Session-ID. More 
specifically, it might cause next UPDATE to contain {A, N}."

Yes, you're right.  I added a new paragraph starting with "With respect 
to the previous two paragraphs ..." that tries to close the hole here.

Anyway, have a look at this modified text and tell me what you think.

Here's a link: http://1drv.ms/1vufda6

Paul

------ Original Message ------
From: "Brett Tate" <[e-mail]>
To: [e-mail]; [e-mail]
Sent: 2/19/2015 3:59:34 PM
Subject: RE: [Insipid] draft-ietf-insipid-session-id-10: comments

>Hi,
>
>Thanks for the response; reply is inline. If I mention the draft, I'm
>referring to February 18 version of "-14".
>
>>  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.
>
>I guess that you were not understanding my use of "generating (instead 
>of
>relaying) subsequent requests and responses".
>
>They are not all necessarily "autonomously generated" unless you 
>consider
>situations such as 3PCC activity stimulated by a user to have been
>"autonomously generated" by the intermediary.
>
>
>>  The text with your addition says the value might be tracked,
>>  but generally the SBC should not alter the UUIDs. Perhaps
>>  this tweak helps?
>
>The current text indicates "intermediaries MUST NOT alter the UUID 
>values".
>
>The "intermediaries MUST NOT alter the UUID values" cannot be met 
>because of
>race conditions. Does INSIPID prefer intermediaries try (and 
>occasionally
>supply incorrect values) or don't try at all? Either way if operators 
>were
>requesting this draft, I assume operators will prefer intermediaries do 
>the
>best they can even though the MUST NOT might occasionally be violated.
>
>
>>  "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."
>
>Doesn't this paragraph violate RFC 7206 requirement 1?
>
>
>>  >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.
>
>Inserting "null" could impact the next Session-ID. More specifically, 
>it
>might cause next UPDATE to contain {A, N}.
>
>
>>  As for the above exchange, why would a 407 be sent in response to an
>>  UPDATE?
>
>Stale nonce, qop not used, et cetera.
>
>
>>  Wouldn't that be sent perhaps on an initial INVITE?
>
>Maybe. It depends upon if UPDATE sent in same direction as 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 instead of UPDATE glare, the 407 and UPDATE were reordered (i.e. 407 
>sent
>in same direction before UPDATE); the 407 with {B,A} might be received 
>after
>UPDATE with {C,A}. Similar to what can occur with intermediaries, A 
>doesn't
>know the correct remote-uuid; it only thinks that it knows the correct
>remote-uuid.
>
>
>>  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 "will contain" conflicts with the prior "MAY track" of section 7
>paragraph 2.
>
>
>>  >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.
>
>As RFC 6141 section 4.8 indicates, SIP provides no mechanism to ensure 
>such
>a thing. From the receivers perspective, it is occasionally 
>indeterminate.
>
>
>>  >> 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?
>
>Concerning the first sentence, the "should be aware" conflicts with the
>prior "MAY track" of section 7 paragraph 2. Similarly, intermediaries
>typically do not know what was "last received by an endpoint"; they 
>know
>what they "last sent towards an endpoint" and have little idea about 
>how the
>endpoint and other intermediaries will reconcile the various race 
>conditions
>(glare, retries, re-ordering, et cetera).
>
>
>>  >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.
>
>It isn't really proprietary. It can be as simple as a B2BUA generating 
>a
>request towards one of the devices; the response indicates a different 
>uuid
>(maybe null). If the B2BUA wants to satisfy the SHOULD, it has to 
>generate
>extra messaging solely to try updating the other endpoint and avoid an
>infinite change loop during the process.
>
>Figure 3 should be updated to comply with sending a request solely to 
>update
>the Session-ID unless you want to highlight in the last bullet section 
>9.3
>that the B2BUA didn't follow the SHOULD. What was the reason why the 
>B2BUA
>didn't fix the remote-uuid within figure 3? Doesn't the section 7 
>paragraph
>3 MUST apply (or is that paragraph intended for a more limited purpose 
>such
>as during the transfer)?