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

From: Brett Tate <[email-masked]>
Date: Fri, 2 Oct 2015 11:41:38 -0400

Hi Paul,

Thanks the response; reply is inline.  I'll send
draft-ietf-insipid-session-id-15 comments/questions separately.

> >General comment: I find the concepts of endpoint and
> >intermediary confusing within the draft.  For instance if
> >a proxy/B2BUA decides to reject an INVITE during call
> >setup, does section 6 or section 7 apply? I assume that
> >section 6 applies (if it didn't relay the related request).
> >If the proxy/B2BUA rejects a mid-dialog request (while
> >acting as an intermediary for the session), section 7
> >applies.  Adding something to section 2 to clarify
> >ambiguity might help.  If a device which can act as endpoint
> >or intermediary rejects a re-INVITE for an unknown dialog
> >by sending 481, should it do so following section 6 or
> >section 7?
>
> Yes, this would be useful.  And it goes along with your
> next issue.
>
>
> >General comment: I find the use of UA within draft
> >occasionally ambiguous concerning if it includes or
> >excludes intermediaries such as B2BUA and proxy's UAS
> >when it is used.
>
> I've made an attempt to address this confusion and to be
> more consistent in terminology, adding some language to
> Section 2 as you suggest, as well.

It helps address the above two comments.  Since it looks like it conflicts
with my mentioned call setup assumption, I'll likely have additional
questions/comments.

> >Section 5 paragraph 7: In my opinion, the MUST should
> >be changed to SHOULD (along with similar changes
> >elsewhere); however since I guess the working group
> >disagrees... Should add text somewhere concerning the
> >impacts of race conditions, retries, CANCEL,
> >authentication, overload, et cetera upon the "most
> >recently received UUID" algorithm.  For instance if
> >"most recently received UUID" was processed as a retry,
> >it potentially isn't the best choice for inclusion as
> >the remote-uuid.

Retry was potentially addressed good enough since I don't think implementers
would interpret "peer endpoint MAY change at any time" as including retries.
However since it doesn't need to pass authentication (and draft overrides
RFC 3261 section 8.2's "all state changes MUST NOT be performed"), I'm not
sure where within the processing steps (like RFC 3261 section 8.2) they will
place the decision to update the stored remote UUID.

Unknown or unsupported request situations are interesting.  Even though the
request is unknown or unsupported, the draft still mandates allowing it to
update the UUID.

Malformed message situations are interesting.  The draft currently allows a
malformed messages to update the UUID.  I can't wait until I hear "I sent
you a malformed message containing Session-ID, why didn't you update the
stored remote UUID?"

Large SIP message situations are interesting.  Even though a device might
reject large messages, the draft still mandates processing the message
enough to update the UUID.

> >Since CANCEL can contain an older UUID, it potentially
> >isn't the best choice for inclusion as the remote-uuid.

You should likely discuss the impacts of CANCEL if you are really intending
to allow it to roll back the UUID.  Otherwise, implementers might not think
that the draft truly intended for the rollback to occur.

> >Because of race conditions, the "most recently received
> >UUID" is not necessarily the most recent UUID sent by
> >the remote endpoint.

Potentially addressed good enough.  However, adding a statement about race
conditions within the draft would help silence complaints if anyone was
thinking that the draft provides a way to ensure all of the devices truly
know the current Session-ID.

> >If a device returns 500 because lower CSeq, it seems
> >strange that the UAS MUST update the stored UUID.

Potentially addressed good enough since I don't think implementers would
interpret "peer endpoint MAY change at any time" as including requests
containing lower cseq.

> >If the "most recently received UUID" hasn't passed
> >authentication (i.e. returning 401, 407, or 403), should
> >the request (or the related ACK) still be allowed to
> >alter the stored UUID?

As far as I know, the draft indicates yes.  Is this acceptable?

> >If an overloaded device returns a failure response
> >(such as 503), is the overloaded device actually
> >supposed to still update the stored UUID to be
> >compliant with this mandate?  If this draft is
> >mandating an overloaded server process an
> >unauthenticated request to update stored information,
> >it should be mentioned within section 11.
>
> Whew!  OK, that's a lot to chew on. :)

As far as I know, the draft indicates yes.  Is this acceptable and should it
be mentioned within section 11?  I'm glad that the draft only indicates that
the B2BUA SHOULD (instead of MUST) communicate the update to the remote
device.

> >Section 6 paragraph 2: Should clarify authentication behavior.
> >For instance, RFC 3261 allows the challenger to behave mostly
> >stateless (such as by not retrying 401/407); however this draft
> >currently appears to mandate maintaining additional information
> >and perform related modifications.
>
> I see value in keeping that state.  This is in line with also
> maintaining the UUID value even in the face of getting a 3xx,
> too.  We want this to effectively persist from the moment the
> user lifts the handset and makes a call to the moment the user
> hangs up the phone.

Sounds okay from a UAC perspective; however since the Call-ID can change, I
don't see how that mandate is always possible from a UAS perspective.

> >Section 7 paragraph 3: If the intermediary knows it is relaying
> >the request to a different session, can it fix the remote-uuid
> >(such as changing it to null)?
>
> For the response aggregation case, definitely.  For what other
> cases are you thinking that should happen?

Basically any cases where the B2BUA likely has a more accurate view of the
current remote UUID.  For instance, section 9.3 example.  Similarly, the
endpoint may be incorrect concerning section 6's "believes may be a new peer
endpoint" check and included non-null remote UUID.  Similarly, consider race
conditions (although it could also cause B2BUA to be wrong).

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 19 Oct 2015 15:13:26 +0000

Brett,

>place the decision to update the stored remote UUID.

Nothing in this draft changes the processing rules.  If a message is 
received and determined to be valid and processed, the UUID is updated 
-- if there is a new UUID.

>request is unknown or unsupported, the draft still mandates allowing it 

One could interpret it that way, though one could equally not update the 
UUID given the message could not be processed.  I think it's a matter of 
whether you trust the message to be valid.

>you a malformed message containing Session-ID, why didn't you update 

No, I think you're reading too much into this.  No sensible 
implementation of any protocol should result in accepting a known 
malformed message and pulling out parts of it for use.  If the message 
is clearly malformed, then the whole thing should be junked.  That's not 
even something that should have to be said at this point.  If the 
message is malformed, the UA should send a 400, not try to pull out some 
part of a malformed message and use it.

>enough to update the UUID.

No, I don't think that's the case.  If a large message is rejected, I 
would not expect the UA to go pull out the UUID and use it.  This is 
similar to the malformed message case.  The SIP stack is going to parse 
the message or discard messages long before the message gets to the 
state machine where it would deal with UUIDs.

>that the draft truly intended for the rollback to occur.

There is no intent for it to roll back a UUID.   The UA sending the 
CANCEL will use the original UUID is used before, but it will not 
include the "remote" part.  That was a change we made in a recent draft 
-- it has to match the orginal INVITE.

Not sure why I would have said "older" :-/

>know the current Session-ID.

The only case, I think, where this is an issue is with certain service 
interaction.  And this is called out in the examples (e.g., in 9.3).  It 
is shown how to address this problem.  Maybe "race condition" was not 
the right term to use, but I don't think there are any problems with the 
current procedures in this regard.

>interpret "peer endpoint MAY change at any time" as including requests

Indeed.  This did not mean to throw out all logical message processing 
;-)

>As far as I know, the draft indicates yes.  Is this acceptable?

If it's a valid response, yes.  If the UA sends an INVITE with {A,N} and 
gets a 407 with {A,B}, then it should accept {B} if the 407 isn't bogus.

>the B2BUA SHOULD (instead of MUST) communicate the update to the remote

If a server is overloaded and not processing messages and, instead, 
returning 5xx, I don't expect it to update the UUID value.  There is an 
assumption here that I don't think needs to be stated, and that is that 
acceptance of a UUID is only done if the message is accepted and 
processed.  Malformed, 5xx, etc. errors should not mean we ignore all 
other processing and go pull out and update a UUID.

>From the UAS perspective, the call is over when it sends back a 4xx.  I 
only meant that the client would maintain this state, not the server.  
If that needs clarification, tell me where to add it, but only the UAC 
should maintain UUID information between INVITE / 3xx, for example.

>conditions (although it could also cause B2BUA to be wrong).

I'm struggling with what other words need to be added here.  I don't see 
where things are going to go unpredictably off course.  We know there 
are cases (esp. service interaction cases) where the two ends might have 
a different view of the UUID values, but the B2BUA is in a position to 
fix the problem, since it likely caused the problem.

If we just get rid of B2BUAs and 3PCC, we would have no problems. But in 
those cases, those devices that causes confusion have to fix it.

Paul