Subject: Re: [Sipping] WGLC comments on draft-ietf-sipping-dialogusage-03

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Oct 2006 17:18:15 -0500

On Sep 11, 2006, at 8:18 PM, Paul Kyzivat wrote:

> I went through the whole -03 version this afternoon. We are down to  
> nit picking time, so I have a bunch of stuff, but it largely only  
> affects form, not the message. This is an important draft and the  
> meat is the right meat.
>
> 	Thanks,
> 	Paul
>
>
> Section 1:
>
> The label for Figure 1 is really hard to see in the position it  
> ended up. (Same is true for Figure 2.) I think it is because it is  
> placed after the message detail. I think it would be better right  
> after the flow diagram.
easy fix

>
> The second paragraph includes: "Multiple REFERs within a dialog  
> create multiple subscriptions, each of which is a new dialog usage  
> sharing common dialog state."
>
> While this is true, it might be confusing. After sending a REFER,  
> it would not be normal to send another until the first either  
> succeeds or fails. Upon either success or failure, it would be  
> normal for the refer subscribe usage to terminate as well. So in a  
> normal case I think you would not normally have multiple  
> *concurrent* refer subscribe usages. It would be possible (for  
> instance the first usage might not end when the REFER succeeds) but  
> that would be "weird".
You're only thinking of transfer.
If anybody ever gets around to the other uses of REFER that had us  
use it instead of a TRANSFER verb, then concurrent REFERs may be more  
normal.

>
> Since the point here in the introduction is simply to motivate  
> multiple usages, maybe some other more plausible example would be  
> less confusing. An example might be: A invites B, B subscribes to  
> KPML of A, B sends REFER to A. This results in an INVITE usage and  
> two subscribe usages in different directions for different events.  
> Another could be: A invites B, B subscribes to KPML of A, A  
> subscribes to KPML of B. I'm pretty sure I know both of these have  
> been implemented, so I guess they are plausible.
Added one of those as another motivational example
>
> Also in section 1: "Usages have state that is not shared in the  
> dialog.  For example, a subscription has a duration.  Multiple  
> subscriptions in the same dialog each have their own duration."
>
> This is again true, but possibly misleading by omission, in that a  
> subscription usage has other state. In addition to duration it has:  
> event type, event id, and a direction. I think either this should  
> be mentioned, or to avoid that complexity it might be ok to say:  
> "For example a subscription has, among other things, a duration."
This is now:
<t>
Usages have state that is not shared in the dialog. For example,
a subscription has a duration, along with other usage-specific state.
Multiple subscriptions in the same dialog each have their own duration.
</t>

>
> Section 2.2:
>
> para 1 nit: s/For space,/To focus on the essential points,/
done
>
> para 2 nit: s/decides skip/decides to skip/
done
>
> In figure 2 I question the termination point for usage 1. Based on  
> the content of section 3.2 it will end on the 200 response to the  
> NOFIFY following F3 rather than on the 200 of the unsubscribe.
Good point. While you could argue this either way, It would be better  
if most of the world send a 200 to that NOTIFY and not a 481.
I changed the figure.
>
> Section 3.2:
>
> Says that a usage is created by 2xx response to SUBSCRIBE, as well  
> as NOTIFY. I think there is some debate whether the 200 actually  
> does create a usage, or if it is only the NOTIFY that does so.
This reflects what 3265 says now.
>
> Says terminated by 2xx response to NOTIFY-terminated. As noted  
> before this contradicts the termination of usage 1 in figure 2.
not anymore
> (Question: is it also terminated if a NOTIFY is not received  
> reporting the expiration of the subscription? If so, when? If too  
> soon then the final NOTIFY will not be processed.)
There is a race condition on allowing subscriptions to expire without  
explicitly unsubscribing. The NOTIFY terminated mustn't be issued  
before the subscription duration has expired, at which
point the watcher may have discarded state. However, I don't see any  
big deal here given what we landed on for 481s inside multiple usages.
I will add that the usage can go away if the subscription expires  
without refresh (if something odd prevents the NOTIFY from getting  
there first).
Adam - for the next time we touch 3265 - you may want to add a  
recommendation for the watcher side to deal with this race gracefully  
(or is it already there)?

>
> Section 4.1:
>
> I think this section could be drastically shortened, simplified,  
> and made easier to comprehend by removing the redundancy. The vast  
> majority of the responses are treated the same as 400 - they affect  
> only the request and don't change status of usage or dialog except  
> by changing the CSeq. But this is said in many different ways. For  
> the most part there are only three outcomes:
> - impacts only transaction, not usage or dialog
> - terminates usage, not dialog
> - terminates dialog and all usages

I'll give this a try. It may (along with trying to catch the running  
train that is GRUU) keep me from finishing this before the blackout.

> Over and above that, there are some nuances that are worth bringing  
> out for some particular responses.

>
> I think this might be handled most concisely by a table with a row  
> for each response. It would indicate which of the the three general  
> treatments apply to it, with an indication if there are special  
> considerations for that one. Then there can be additional text,  
> following the table, for each one that has some special  
> considerations to note.
>
> In discussion of 400: s/complaint/compliant/
No - it really did mean complaint.

>
> In discussion of 403: This means it is impossible to explicitly  
> request termination of the subscription. If the goal was to  
> announce termination of the subscription, what should be done? I  
> think the best that is possible is for the UAC to declare the usage  
> ended, while the UAS will not know it is ended until it attempts to  
> send something else in the usage and receives a 481 response.
This is essentially the same question we have on what to do when you  
get a non-200 response to a BYE (that you can't fix).

>
> Discussion of 483 says "the the agent should attempt to gracefully  
> terminate this usage and all other usages that share its dialog."  
> It is not clear from this language if that means additional  
> signaling should be attempted to achieve this graceful termination,  
> or whether only local actions should be taken. Remote actions don't  
> seem useful in this case. Would be good to be explicit about it.  
> Perhaps say something like:
> "the agent should terminate this and all other usages as gracefully  
> as is possible without sending further messages in the dialog."  
> Whatever the final language is, it applies to several responses.
Its as specific as it can be, I think. There may be cases where a  
remote action might succeed (consider an INVITE  blowing up because  
some misconfigured bunch of appservers are pushing too many routes,  
but a BYE will get through).
>
> Discussion of 500: here talks about attempting to gracefully  
> terminate a usage or treat it as terminated. Not clear what the  
> difference between these is. Similar to comment about 483.
Again as specific as it can be. If there is some extra signaling that  
might work (see the BYE above), give it a shot, otherwise, treat the  
usage as gone.

>
> Section 4.4: It might be worth noting that it is problematic to  
> send a message for a different usage between the time the target  
> refresh request is sent and the time a final response to it is sent  
> or received. During this period its impossible to know which target  
> is active at the other end. (Of course this applies to requests  
> within a usage too, but people might not of considered it in this  
> context.) I would say that this should be left to the race- 
> conditions draft, but its trying to avoid dealing with multiple  
> usages.
>
Yeah - this is not unlike the early dialog retargetting behavior that  
we decided to not discuss here. To make sure people have considered  
it, I'll add a warning to the end of that section pointing out that  
this scenario requires careful analysis before implementation.
> Section 5:
>
>    When designing new applications that use SIP dialogs, do not
>    construct multiple usages.  If a peer attempts to create a second
>    usage inside a dialog, refuse it.
>
> I think there can be some ambiguity in what is meant by the term  
> "new application". When I first read this, I was thinking it meant  
> "a new implementation of a UA". So I thought you were suggesting  
> that new implementations of a UA, when implementing transfer,  
> should refuse to support multiple usages. This is an excellent way  
> to create interop problems.
>
> After thinking about it I decided you couldn't possibly mean that,  
> and that you must be talking about designing new features for which  
> there are no existing implementations. In that case I agree it is  
> fine to avoid using multiple dialog usages. Right this second I  
> don't have any wording in mind that gets the point across without  
> being too verbose, but I am certain it must be possible.
>
>     When designing a new feature that will require new implementation
>     by all participating UAs, avoid usage of multiple dialogs.
>
> I still struggle with the part about refusing attempts to create a  
> second usage because I am not certain that you can always know  
> whether the peer is trying to carry out the new feature, or an old  
> feature in the same context. I'm sure it is possible to construct  
> some more specific guidelines, but I think it will take some work  
> to get them right.

You are correct that I did not mean new phones have to refuse to work  
with existing transfer systems.
Taking your suggestions, here's my next attempt to capture the  
recommendation without leading someone that far astray:

<t>When designing new applications or features that use SIP dialogs,  
do not
require endpoints to construct multiple usages to participate in the  
application
or use the feature. When designing endpoints, address the existing  
multiple usage
scenarios as best as possible. Outside those scenarios, if a peer  
attempts to
create a second usage inside a dialog, refuse it.</t>

>
> Section 5:
>
> The paragraph before the call flow says: "A new header, Target- 
> Dialog: perhaps". The "perhaps" seems wrong here. Maybe it was  
> included before the RFC 4538 was complete. Now there probably  
> should be a reference to that RFC.
That's exactly what happened. I'll update.

>
> In the message detail for figure 3, the stuff for gruu is not  
> consistent with the latest draft. Minimally the gruu URIs should  
> have a "gruu" uri parameter, and the "Supported:gruu" can then be  
> omitted. (That is probably sufficient for this example.)
Speaking of becoming Overcome By Events...

>
> The paragraph:
>
>    Message F2 lets Alice know that Bob understands GRUUs.  If Bob did
>    not indicate this support, the original multi-usage approach to
>    transfer would have to be used.
>
> is now not quite right either. Neither Alice nor Carol need to know  
> that bob understands gruus for this scenario to work. Its bob that  
> needs to know Alice and Carol support gruu. Bob learns that from  
> the gruu parameter in the Contacts in messages F1 and F4. If alice  
> doesn't support then the R-URI for the REFER should be Alice's AOR,  
> and if carol doesn't support then the Refer-To should be carol's AOR.
>
> Of course this may change as a result of the WGLC on gruu.
>
> (I was going to try to provide replacement text for this, but I  
> can't do it piecemeal. It needs a bunch of small changes  
> distributed through it. I can attempt the whole thing if you want.
I'll get it, but I'll probably ping you for sanity checks.
>
> Section 6 - Security Considerations:
>
> I find the warnings in the first paragraph to be excessively dire.  
> I see two kinds of exploits by an "evil doer":
I can't find a way to reduce the strength that I'm comfortable with -  
I think this is another place we just disagree.
>
> - MiTM attack. If the bad guy can get into a position to inject  
> messages into the dialog, then it can attack multiple usages rather  
> than just one. But if it could get into one dialog, why not  
> another? This seems to be a matter of only doing something quickly  
> before the bad guy can crack your security. It could be quick with  
> one usage or several. So I don't see the significance of this  
> exploit as something special to multiple usages.
The ambiguity in places around handling multiple usages is the place  
that's more open to attack than just the field of single usage  
dialogs. Consider the problems you point to with what it means to  
have two target refresh requests on different usages open, and how an  
attacker might induce an endpoint to do the wrong thing (by modifying  
contacts in responses for example).

>
> - At the UAC or UAS, there might be some kind of multiplexer that  
> combines usages into a single dialog. If the code implementing the  
> various usages is otherwise independent and untrusting of the code  
> implementing the other usages, then there is a threat that malice  
> or incompetence in an application implementing one usage could  
> screw up a different usage. But that isn't really a fault against  
> multiple usages, it is the fault of multiple usages in differing  
> trust domains. This is a kind of implementation scope that isn't  
> often addressed in the sip specifications, so I don't know why it  
> would be addressed here. But if it is, I think the scope should be  
> suitably narrowed. I expect that the more common case is that all  
> the usages are implemented within the same "application".
I don't think this document does or should bring that up.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 20:04:00 -0400

Major snipping here. I was happy (modulo our basic philosophical 
differences) with all of your other changes. Only this one thing left:

Robert Sparks wrote:
> Paul Kyzivat wrote:
>> consistent with the latest draft. Minimally the gruu URIs should have 
>> a "gruu" uri parameter, and the "Supported:gruu" can then be omitted. 
>> (That is probably sufficient for this example.)
>> needs to know Alice and Carol support gruu. Bob learns that from the 
>> gruu parameter in the Contacts in messages F1 and F4. If alice doesn't 
>> support then the R-URI for the REFER should be Alice's AOR, and if 
>> carol doesn't support then the Refer-To should be carol's AOR.
>>
>> (I was going to try to provide replacement text for this, but I can't 
>> do it piecemeal. It needs a bunch of small changes distributed through 
>> it. I can attempt the whole thing if you want.

I think you just missed this. Since we are in blackout now, can't fix it 
anyway. Maybe we should just work through it in San Diego.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Oct 2006 19:49:51 -0500

Well - I tried to get all of that - looks like I missed some text  
(rats).

Blackout or no, we can keep a working copy for submission later. If  
we're still not happy with where it is when we get to San Diego, I'm  
definitely game
to spend some time there putting the final work in.

RjS

On Oct 24, 2006, at 7:04 PM, Paul Kyzivat wrote:

>>> is now not quite right either. Neither Alice nor Carol need to  
>>> know that bob understands gruus for this scenario to work. Its  
>>> bob that needs to know Alice and Carol support gruu. Bob learns  
>>> that from the gruu parameter in the Contacts in messages F1 and  
>>> F4. If alice doesn't support then the R-URI for the REFER should  
>>> be Alice's AOR, and if carol doesn't support then the Refer-To  
>>> should be carol's AOR.
>>>
> I think you just missed this. Since we are in blackout now, can't  
> fix it anyway. Maybe we should just work through it in San Diego.
>
> 	Paul