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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 2 Nov 2001 01:04:01 -0500

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, November 01, 2001 1:35 AM
> To: Gonzalo Camarillo
> Cc: Romel Khan; 'Robert Sparks'; Shan Lu; 'IETF SIP Mailing List';
> Jonathan Rosenberg
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> >If you do not think that not being able to hang up a call is harmful
> >then we live in different worlds.
> 
> If my UAC works correctly I will be able to hang up the call... Yes,
> there is a small chance, if the caller hangs up very fast, that the
> phone will ring for a while, until the UAC realises what has happended
> and sends a new CANCEL or BYE (depending on the type of response it
> first receives for the INVITE).

New CANCEL will do nothing, as it will be seen as a retransmit.

BYE will terminate only the leg which generated the 1xx, all others keep
ringing. BYE is not the same as CANCEL.

>  
> >>Second, IF it will be a requirement to wait for the 1xx, 
> then I think it
> >>also must be a requirement to send a 1xx in the first plavce
> >bis-05 says that the server transaction MUST send a 100 Trying unless
> >another response will be sent in 200 ms.
> 
> So, who is going to start a timer for 200 ms??? Wouldn't it 
> be much more
> CLEAR and SIMPLE to simply write that the server MUST send a 
> provisional
> response as soon as it receives the INVITE?

There are redirect servers that return a final response instantly. In these
cases, the 100 is wasteful.

> >>Which scenario? Loosing a message, or hanging up in less than half a
> >>second? :)
> >>
> > 
> >Both at the same time.
> 
> And, how often will both at the same time happen? 

Frequently enough. I'd like to have a protocol that is reasonably correct.
This failure is quite bad if it should happen.

Christer later writes:
> 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), 

That is FALSE. Unauthenticated requests can be responded to statelessly. I
have posted a note that concisely outlines the attacks possible with server
side buffering. You seem to ignore them.

-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: Fri, 02 Nov 2001 08:19:51 +0200

Jonathan,

>>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),
>
>That is FALSE. Unauthenticated requests can be responded to statelessly. >I have posted a note that concisely outlines the attacks possible with >server side buffering. You seem to ignore them.

I am NOT ignoring them. However, which I have said, if a third party
really is able to send messages around just like that, there is much
more damage he can do than the stuff related to this specific case. He
can hang up calls, establish calls which will be billed to someone
else... whatever... 

Regards,

Christer Holmberg
Ericsson Finland

---

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

<excerpt 1>
Jonathan wrote:
> Christer wrote:
> > Why? If the UAC sends CANCEL, receives 481 (the CANCEL reaches the
> > server before the INVITE), and then starts receiving 1xx provisional
> > responses for the INVITE it can send a new CANCEL, which should cancel
> > ALL legs.
>
> Sorry, that is not correct. This CANCEL will look identical to the
previous
> one, and therefore be treated as a retransmission, returning once more the
> same response, 481, and having no effect.
</excerpt 1>

<excerpt 2>
> side buffering. You seem to ignore them.
</excerpt 2>

Do these 2 excerpts contradict?

If a server receives a CANCEL and it has no corresponding INVITE it responds
with 481, but it maintains transaction state in order to handle
re-transmissions.

If the server does not maintain transaction state for the CANCEL (responses
statelessly), and later receives an INVITE and then receives a CANCEL (a
second identical cancel) for that INVITE, it would cancel the INVITE.

I strongly agree that a CANCEL should not be sent until a 1xx response if
received. But is the server (specifically a proxy) required to maintain
transaction state for the CANCEL such that it would see the second CANCEL as
a retransmission?

cheers,
(-:bob

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Nov 2001 17:36:10 +0200

Hello,

> can hang up calls, establish calls which will be billed to someone

Christer, you DO ignore them. A note was posted stating that CANCEL is
hop by hop and thus cannot be authenticated using the mechanisms you use
for INVITEs, re-INVITEs, BYE, etc...

Besides, if you still think that waiting for the 100 response is a
problem, I believe you should include Van Jacobsson in this thread to
tell him that his cogention control for TCP makes not sense. Or even
better, do some kernel programming and modify the TCP stack that comes
in your OS.

If you send an INVITE and there is no 100 Trying back it is because the
network is down. If you were using TCP, the TCP ACK for the segment that
contained the INVITE will never arrive either. Since you are using slow
start and your initial window size is one, TCP WILL NOT SEND THE CANCEL
UNTIL A TCP ACK CARRYING THE 100 TRYING IS RECEIVED!!

So, please explain me why the fact that TCP behaves like that is not a
problem for anyone and the same behavior for UDP seems so awful.

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Nov 2001 21:15:20 +0200

Hi,

>for INVITEs, re-INVITEs, BYE, etc...

I did read that note, and I said that we could allocate state for the
CANCEL. Then it was said that that would cause the risk of allocating
lots of state by a third party, and maybe even block calls, and then I
said that unless we use a secure network there will still be ways to
mess things up. Or, am I wrong on that?
 
>network is down.

My point is NOT about IF there will be a 100 Trying or not. If the nodes
work correctly, there WILL be a 1xx (or a final response directly sent).
The issue is that there MAY be a case (even if very unlikely) where the
caller will hang up the phone before the response is received, and that
we will have to implement support for that (using some flag, buffering,
whatever...).

>If you were using TCP, the TCP ACK for the segment that

Did I ever say that?????? However, what TCP does with my message doesn't
affect the SIP application level. Also, if INFOs, PRACKs, COMETs etc are
used it may take even longer before the CANCEL is really sent to the
network, but my SIP application doesn't have to care about that, does
it?
 
>problem for anyone and the same behavior for UDP seems so awful.

I am FULLY aware what UDP does, and what it does not do, and I am FULLY
aware about that messages may be delivered in the wrong order when it's
used (I NEVER said that there couldn't be a case where the CANCEL
reaches the server before the INVITE if we don't wait for a response),
and that we have to handle that on the SIP application level. The
discussion has been (at least from my point of view) HOW we handle it -
NOT IF we have to handle it.

All this really makes me realise that the CSeq, which is supposed to
help us order messages, doesn't help us at all (except than matching the
request with the response...) in this case, where message ordering is
very critical, but that's another story...

Anyway, which I said in the previous mail, since the majority wants us
to use the wait-for-1xx mechanism I will accept that. I never said that
it won't work, but I wanted to discuss alternative solutions.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Nov 2001 21:43:23 +0200

Hi,

> mess things up. Or, am I wrong on that?

Yes, you are wrong. You are talking about something completely
different. The problem you are thinking of is a established call between
two parties. Then, you call "the 3rd party" to the attacker. The problem
we are taking about does not involve any 3rd party. It is created by an
entity that sends CANCELs to a proxy or UAS. Only the attacker and the
server.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Nov 2001 21:34:06 +0200

Hi,

>different. 

I am talking about SIP security. A different CASE, but the same issue:
3rd party/attacker/whatever sending weird messages to the server. In one
case before the INVITE has reached the server, and the other case after
the INVITE has reached the server. By not allocating state you solve
only the first issue.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Nov 2001 22:18:54 +0200

Hello,

> the INVITE has reached the server. By not allocating state you solve

OK, I have changed the subject of this email.

In order to authenticate a CANCEL (that arrives after an INVITE), you
can use several mechanisms. You have to make sure that the entity that
now sends the CANCEL is the same as sent the INVITE. You can use TLS or
IPSec, since this is a hop by hop problem. You could also check the
source IP address, although this does not give you a great deal of
security.

Regards,

Gonzalo

---

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

Hi,

My last mail on this issue :)

>source IP address, although this does not give you a great deal of

I agree, but not we are not talking about basic SIP functionality
anymore, but SIP security.

Also, if you use a security mechanism you probably won't have the
problem with non-call related CANCELs either, and if a server receives a
CANCEL for which it doesn't have call state it will most likely receive
an INVITE short after.

And, even authenticated users can mess up servers before or after the
call is established, but that is another issue, and must most likely be
handled on a higher network management level.

Anyway, I AM fine with the 1xx solution. Not because it would solve
every possible CANCEL related SIP attack in a non-secure SIP network,
but at least it will solve the original issue of this thread.

Case closed :)

Regards,

Christer Holmberg
Ericsson Finland