Subject: [Sip] RE: wording in the dialog package on mid-dialog requests

From: "Paul D.Smith" <[email-masked]>
Date: Tue, 8 Feb 2005 17:31:01 -0000

Rohan,

I think the text is better and now ensures that a NOTIFY response
does not take down the dialog.

However I am still concerned about the whole idea that sending
a BYE ends a dialog.  I believe this is tantamount to making a
BYE pointless.  The reason for saying this is we are removing
ability to either challenge a BYE, or to indicate that a BYE
failed to reach the UAS as a result of a temporary problem.

If I receive either a 407, 401 or 486 response, I MUST be able
to resend the BYE but by your definition, the dialog has
already ended.  This seems simply wrong and, as I've pointed
out before, totally contrary to the text in RFC3261.  Now if
this is the route that the WG wants to take then so be it, but
we then need to start making associated changes to
SIP.

If we are going to say "when you send a BYE, the dialog is ended"
then I propose that we need to clarify SIP behavior as follows.

1. A BYE cannot be challenged.  Umm, can't see people liking that
   but since the dialog ends on sending the first BYE, there is 
   no dialog so its over!  Perhaps we could indicate that a
   UAS can, should it wish, reject an unauthenticated BYE but it
   should NOT expect to receive a better BYE.

[There is obviously a DoS attack possible if we allow any
 unauthenticated BYE to end a dialog]

2. A UAS must determine for itself when a dialog has ended in case
   a proxy sends a 486 and the UAC never resends a BYE.  Now this
   is clearly an application level requirement already in case, 
   for example, a lost network connection rules out all chance
   of a BYE ever arriving.  But your change makes is a much more
   common occurrence ?? caused by a short-term overload.

Thoughts?
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 28 January 2005 20:32
To: SIP
Subject: wording in the dialog package on mid-dialog requests

Hi Paul,

To clarify the difference between a 481 to a NOTIFY (intended for a 
subscribe usage), and a 481 to a request specific to the INVITE usage 
of a dialog, I propose the following small change to the text in the 
dialog package.  I believe this addresses your concern with respect to 
the dialog package specification itself. In general, we need to be more 
specific about the context of error responses.

thanks,
-rohan

Current Text
> Once in the confirmed state, the call is active. It can transition to 
> the terminated state if the UAC sends a BYE or receives a BYE 
> (corresponding to the "local-bye" and "remote-bye" events as 
> appropriate), if a mid-dialog request generates a 481 or 408 response 
> (corresponding to the "error" event), or a mid-dialog request 
> generates no response (corresponding to the "timeout" event).

Proposed Text
> Once in the confirmed state, the call is active. It can transition to 
> the terminated state if the UAC sends a BYE or receives a BYE 
> (corresponding to the "local-bye" and "remote-bye" events as 
> appropriate), if a mid-dialog request corresponding to the INVITE 
> usage of that dialog (currently PRACK, UPDATE, INFO, and reINVITE 
> requests) generates a 481 or 408 response (corresponding to the 
> "error" event), or if any mid-dialog request generates no response 
> (corresponding to the "timeout" event).

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

---

From: David R Oran <[email-masked]>
Date: Tue, 8 Feb 2005 13:10:49 -0500

On Feb 8, 2005, at 12:31 PM, Paul D.Smith wrote:

> BYE pointless.
No more pointless than a TCP FIN. It's a polite way of saying "I'm 
throwing my dialog state away so  it probably makes sense for you to 
trash yours too". Perhaps you think it's pointless because you thought 
a BYE was somehow had more semantics?

> The reason for saying this is we are removing
Where does the text say I can't challenge a BYE?  I certainly don't 
want to believe a BYE unless it is properly authenticated because that 
opens a DoS attack. I don't follow your second sentence, since I can't 
respond to a request I never received, so there's not way to indicate 
this from the UAS to the UAC.

> to resend the BYE
why?

> but by your definition, the dialog has
> already ended.
and by mine. You can't cause dialog state that has evaporated (which is 
what I think 401, 407 and 486 each imply) to somehow get reconstituted 
such that a BYE will be processed as if the dialog existed. We could 
change the semantics of BYE such that it is idempotent, but I bet 
people would react to that the way they react to similar suggestions 
I've made over the years (I remember the flameage I got for a directory 
system where if you deleted a non-existent directory entry, the system 
just said "OK, deleted". In fact, if you tried to delete an entry you 
didn't have read privileges on, it also said "OK deleted". I'll leave 
it to you to figure out why this has nice security properties.).

>   This seems simply wrong and, as I've pointed
Since a dialog is a distributed state machine, it is not possible to 
say this, and I don't think that it does say this anywhere.

>    should NOT expect to receive a better BYE.
This would be wrong and I don't think anybody is suggesting it.
>    common occurrence ?? caused by a short-term overload.
I don't follow this. If you get a 486 from a proxy you can be pretty 
sure no other request is going to get through for that dialog, so 
what's the point of keeping your state around or sending more requests?

>> (corresponding to the "timeout" event).
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 13:42:39 -0500

I would be much happier if every reference to "dialog" was replaced with 
"invite-dialog-usage" or something like that. The whole concept that a 
BYE causes a *dialog* to go away, when there could still be some other 
usage of that dialog in progress, is broken.

Othewise I agree with Dave.

	Paul

David R Oran wrote:
> trash yours too". Perhaps you think it's pointless because you thought a 
> BYE was somehow had more semantics?
> 
> Where does the text say I can't challenge a BYE?  I certainly don't want 
> to believe a BYE unless it is properly authenticated because that opens 
> a DoS attack. I don't follow your second sentence, since I can't respond 
> to a request I never received, so there's not way to indicate this from 
> the UAS to the UAC.
> 
> change the semantics of BYE such that it is idempotent, but I bet people 
> would react to that the way they react to similar suggestions I've made 
> over the years (I remember the flameage I got for a directory system 
> where if you deleted a non-existent directory entry, the system just 
> said "OK, deleted". In fact, if you tried to delete an entry you didn't 
> have read privileges on, it also said "OK deleted". I'll leave it to you 
> to figure out why this has nice security properties.).
> 
> Since a dialog is a distributed state machine, it is not possible to say 
> this, and I don't think that it does say this anywhere.
> 
> sure no other request is going to get through for that dialog, so what's 
> the point of keeping your state around or sending more requests?
> 
>> Thoughts?
>> Paul D Smith
>> Network Protocols Group