Subject: RE: [Sip] Bis-05 question: CANCEL

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 31 Oct 2001 23:16:28 -0500

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 7:45 PM
> To: 'Christer Holmberg'
> Cc: 'IETF SIP Mailing List'
> Subject: RE: [Sip] Bis-05 question: CANCEL
> 
> 
> > >Don't you undestand that what the harm 
> > >that you can produce by being
> > >unable to hang up a call because the 
> > >CANCEL made it before the INVITE is
> > >much higher than having to wait for a 
> > >provisional response?
> > 
> > First, maybe I don't get the point, but 
> > exactly what "harm" could this produce?
> 
> I think that the bis-05 made an attempt
> to address some of the race conditions
> that can occur in SIP.  It is now up
> to the SIP community to provide comments.

Correct. This is one of a handful of open issues that we did proposed
resolution for in bis-05.

> 
> One alternative is to queue the CANCEL
> at UAS/proxy waiting for the associated 
> request.

Right. The issue with that is that is that it opens a DoS attack. CANCEL
can't be authenticated like other requests since its hBh. Thus, its
authenticated by having it come from the same place the request came from
(and so tls, for example, could be used). This means you trust it if you
trust the request its cancelling. If you buffer at the server, you would
have to buffer the cancel even before an authenticated request arrived. THis
means that someone can send CANCEL to establish state at the server, and
then never send a corresponding request. There is no easy way to defeat this
except to prevent it as we have proposed. 

> 
> Another alternative is for SIP devices 
> to actually start using the Expires 
> header and/or the UAS to remain in 
> ringing for a "maximum" time.  I assume 
> that most UAS implementations will 
> not allow a call to remain in alerting
> state any longer than 3 minutes unless
> they are trying to use 182 type 
> functionality.

I don't see how this helps. In my initial INVITE, I don't know how long I
want it to ring for, so there is no Expires. A second later I decide to hang
up. Its too late to use the Expires in the INVITE since its been sent. 

> > Otherwise there MAY be cases 
> > (if no 1xx is sent) where the UAC can't
> > terminate the call before it has 
> > received the 200 final response...
> 
> Yes.  A malicious server could intentionally
> delay sending a 1xx in an attempt to help 
> produce a billing situation by delaying
> the ability for the originator to CANCEL
> the request.

Why bother? Just send a 2xx and ignore the cancel. Hey, ignore the INVITE
too. Malicious servers are a whole other can of worms, that are nearly
impossible to defeat with protocol means. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Christer Holmberg <[email-masked]>
Date: Thu, 01 Nov 2001 10:41:44 +0200

Hi,

>There may be a third option that I don't remember having been discussed,
>namely that the client sends the CANCEL immediately but the server just
>sliently drops it if it cannot associate it with a request. That is, it
>doesn't respond and doesn't install transaction state. The client will
>continue retransmitting CANCEL and the original request in parallel (as
>per usual) and the CANCEL will continue to be dropped by the server
>until the original request is actually received. Same procedure would
>apply to proxy servers.
> 
>This will no doubt be violently hated by some and I'm not necessarily
>proposing it anyway ;).  Apart from treating CANCEL even more specially
>than is already the case it means a UAS might ring the phone even though
>the call was cancelled. Although actually, that should be no worse than
>if the INVITE has been received immediately and no worse than waiting
>for a 1xx.

What you propose would probably work, but that would cause extra traffic
on the network, and I am not sure it's a very good idea from a protocol
logic point of view either. That is, of course, a matter of taste,
though :)

Another option could be: 

Whenever a server receives the INVITE, it checks if it has recently
received a CANCEL/BYE for that call. Today, the server must anyway keep
state for the CANCEL (and every other method) for a certain time after
it has sent the final response (to handle re-transmissions etc), so from
a state machine point of view that would not cause any changes. The only
change would be the check when the INVITE is received.

Then, it wouldn't matter if the INVITE comes after the CANCEL, because
the server would not accept the INVITE - and no phone would start
ringing.

Regards,

Christer Holmberg
Ericsson Finland

> 
> Anders
> 
> Jonathan Rosenberg wrote:
> >
> > >

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 1 Nov 2001 20:30:12 -0500

> except to prevent it as we have proposed. 

I guess that the bis-05 proposal should
also reflect that the CANCEL MUST be
queued at the transaction stateful proxy 
until it receives a 1xx for the INVITE
to avoid proxy delivering the CANCEL
before the INVITE.  It would apply to
both forking and non-forking situations.

Maybe Anders idea of dropping an unknown 
CANCEL instead of sending a response
isn't so bad. :)

> INVITE since its been sent. 

It helps by establishing a maximum time within 
which a final response should be generated.
I agree that it doesn't work as quickly as
queuing the CANCEL at the UAC.  I also agree
that it limits how long a call can remain in
an alerting state without the usage of 
draft-rosenberg-sip-early-media to send an 
overlapping re-invite to replace the
request. :)

Using Expires also fixes the UAC/proxy/network 
failure problem that prevents the CANCEL 
from getting to UAS.  Hopefully if no Expires 
was used, a UAS would still be smart enough 
to not remain indefinitely in alerting state.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Nov 2001 10:44:36 +0200

Hi,

>have to buffer the cancel even before an authenticated request arrived. >THis means that someone can send CANCEL to establish state at the server, >and then never send a corresponding request. There is no easy way to >defeat this except to prevent it as we have proposed.

No matter what request is sent to the server, it still must keep state
for it for a certain time (until Timer J fires, according to the state
machine on page 106), to handle re-transmissions etc. Of course, if that
is NOT true when a 481 response is set, the situation is different...

And, if the third party wants to BLOCK calls, it's not enough if he
sends CANCELs with different Call-IDs. He must also know the To, From
and CSeq numeric header values, since they MUST match in the the INVITE
and CANCEL.

And, assume that the INVITE DOES reach the server first, and the third
party sends the CANCEL immedeately after that. It's not a DoS attack,
but it still messes up the call.

ANYWAY, if I'm the only one who doesn't like the wait-for-1xx idea I
think we should stop the discussion, use that mechanism, and move
forward. I am pretty sure there are lots of other, more important
issues, to solve :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 2 Nov 2001 10:43:19 -0500

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: Friday, November 02, 2001 3:45 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]; 'IETF SIP Mailing List'
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> 

Count me as a firm second :-)

Actually I believe there is a solution without having to wait for 1xx.
We need two modifications on how to handle CANCEL:

Mod 1) CANCEL is handled statelessly at the server side if there is no
matching INVITE. In other words, a 481 response is sent and the
transaction state is destroyed.

Mod 2) CANCEL transaction client should retransmit CANCEL till 200
response is received or a maximum retransmission number has been
reached. In other words, a 481 response does not change the state to
"Completed" (Figure 6).

A brief note on Mod 1: stateful proxy already follows this rule in
bis-05, see section 16.8, line 2449.

With these two mods in mind, here is how CANCEL works:

Case 1: No SF proxy

UAC sends INVITE and then CANCEL. If INVITE beats CANCEL at UAS, CANCEL
is responded with 200. Phone stops ringing if it has been ringing
before. Everybody happy. If CANCEL beats out INVITE, CANCEL is responded
with 481 statelessly (mod 1). Hence UAC will resend CANCEL (mod 2).
Eventually a retransmitted CANCEL will arrive after INVITE.

Case 2: SF proxy between UAC and UAS

UAC sends INVITE and then CANCEL. If the SF proxy receives INVITE and
then CANCEL, the CANCEL will be responded with 200 and the proxy will
generate CANCEL on all branches of INVITE. From there, we are back to
Case #1. If the proxy receives CANCEL before INVITE, it will statelessly
forward this CANCEL downstream and the UAS will respond with 481
assuming the CANCEL beats out INVITE at the UAS. So UAC will retransmitt
CANCEL which eventually will be received by the proxy after INVITE. Back
to Case 1.

We are already doing so many special things for CANCEL. I don't think
these two mods are that much a big deal, especially they are transaction
layer. Compared to wait-for-1xx, this approach maximizes the chance that
INVITE can be cancelled in shortest time (and hence chance for dead
phone syndrome).

Comments/fire welcome.

Regards,

Shan Lu
sentitO Networks

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 2 Nov 2001 11:22:09 -0500

I'm sorry, but I am opposed to changing the way CANCEL works and add yet
another special case. The current methods put no excess burden on the UAC.
The UAC is already required to maintain transaction state until it completes
or times out.

I don't see having the called party's phone ring a few seconds longer when
there is congestion to be all that much of the problem. How many times have
you picked up your ringing phone and said "hello" and there is no one there?
It has happened to me twice this week and I don't get that many calls. I
don't blame the telephone company, I just figure the calling party hung up.

more comments below

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Shan Lu" <[email-masked]>
To: "'Christer Holmberg'" <[email-masked]>; "'Jonathan
Rosenberg'" <[email-masked]>
Cc: <[email-masked]>; "'IETF SIP Mailing List'" <[email-masked]>
Sent: Friday, November 02, 2001 10:43 AM
Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution

> Eventually a retransmitted CANCEL will arrive after INVITE.

The UAC is required to be re-transmitting the INVITE until it gets a 1xx.
Now you want it to keep retransmitting the CANCEL too? Sounds like you're
doing twice the work.

> CANCEL which eventually will be received by the proxy after INVITE. Back

CANCEL is hop-by-hop. The SF proxy would respond with 481. It would not be
sent downstream. Do you see the extra burden you are placing on the proxies?

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 2 Nov 2001 12:02:46 -0500

Hello,

> Behalf Of Bob Penfield
> Sent: Friday, November 02, 2001 11:22 AM
> To: 'IETF SIP Mailing List'
> Subject: Re: [Sip] Bis-05 question: CANCEL -- Proposed solution
> 
> 

I'd like to point out two facts with wait-for-1xx: 1) the phone could be
ringing much longer than a few seconds after the caller has hung up and
2) In absence of 100 Trying (which some people may have very good reason
that UAS shouldn't send right away), you are guaranteed to ring the
callee phone EVERY SINGLE time an INVITE goes out, even if caller hangs
up right away.

Commnets on burden part below. 

> Now you want it to keep retransmitting the CANCEL too? Sounds 

The UAC is required to have a FSM for CANCEL in any case. With this mod,
that state machine just remains in the "Proceeding" state a bit longer.
> sent downstream. Do you see the extra burden you are placing 

This is already specified in bis-05, see 16.8, line 2449. I just
extended to UAS.

Regards,

Shan Lu