Subject: CANCEL: Hop-by-hop or end-to-end?

From: Anders Kristensen <[email-masked]>
Date: Mon, 28 Feb 2000 13:01:09 +0000

My understanding is that CANCELs are hop-by-hop requests only, i.e.
proxies respond to CANCELs and then may or may not themselves CANCEL
branches of the corresponding proxied request. These CANCELs then have a
single Via header identifying the proxy.  However, I don't think it
states this conclusively in the spec.  Also this seems to me to be an
(insignificant maybe) security hole as CANCELs cannot be authenticated
by the caller?

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Feb 2000 11:53:19 -0500

Anders Kristensen wrote:
> single Via header identifying the proxy. 

True, excepting that stateless proxies will forward CANCEL, so there may
be more than one Via if there are stateless proxies between.

> However, I don't think it
> states this conclusively in the spec. 

Well, there is this text:

> The Call-ID, To, the numeric part of CSeq and From headers in the
>    CANCEL request are identical to those in the original request. This
>    allows a CANCEL request to be matched with the request it cancels.
>    However, to allow the client to distinguish responses to the CANCEL
>    from those to the original request, the CSeq Method component is set
>    to CANCEL. The Via header field is initialized to the proxy issuing
>    the CANCEL request. (Thus, responses to this CANCEL request only
>    reach the issuing proxy.)
> 

Particularly, the last sentence. It could be clearer. 

 Also this seems to me to be an
> (insignificant maybe) security hole as CANCELs cannot be authenticated

I think you mean by the called party. Yes, they cannot be authenticated.
The problem is that the CANCEL can be generated by any proxy along the
path. So, the right way to handle CANCEL security is via hop by hop
stuff. If, for example, there is an IPSEC connection between proxies,
some request initiated through that connection can only be cancelled
through that connection also. In the absence of IPSEC, you should only
accept a CANCEL from the same IP address that sent the request. THe spec
is completely silent on these issues. They are being worked on.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Alan Johnston <[email-masked]>
Date: Mon, 28 Feb 2000 13:35:11 -0600

The current version of the SIP Telephony Call Flow Examples document
(draft-johnston-sip-call-flows-00.txt) incorrectly shows end-to-end behavior for
CANCELs.  This is corrected in the new draft which will be published this week.

Alan Johnston
MCI WorldCom