Subject: [Sip] [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 25 Oct 2008 19:26:17 +0200

Hi, I've a doubt about what should be the correct response for an initial 
SUBSCRIBE (Event: dialog) if the indicated dialog doesn't exist in the 
recipient of the SUBSCRIBE.

This doubt comes after reading the today submitted draft "Dialog Event foR 
Identity VErification":
  http://www3.ietf.org/proceedings/staging/draft-kuthan-sip-derive-00.txt

In page 14 of this draft there is a flow about a suspicious call (spoofed 
From). The flow is correctly displayed using fixed length typography, if it's 
not your case refer to page 14 of the draft.

    Attacker        Alice   Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob
    |               | INVITE F5      |                |                |
    |------------------------------------------------>|                |
    |               | 100 F6         |                |                |
    |<------------------------------------------------| INVITE F7      |
    |               |                |                |--------------->|
    |               |                |                | 100 F8         |
    |               |                |                |<---------------|
    |               |                |                | SUBSCRIBE F9   |
    |               |                | SUBSCRIBE F10  |<---------------|
    |               | SUBSCRIBE F11  |<---------------|                |
    |               |<---------------|                |                |
    |               | 481 F12        |                |                |
    |               |--------------->| 481 F13        |                |
    |               |                |--------------->| 481 F14        |
    |               |                |                |--------------->|

So, Bob sends an initial SUBSCRIBE to Alice AoR (the received From uri in the 
INVITE F5/F7) with the half-dialog data:

   SUBSCRIBE sip:[email-masked] SIP/2.0
   From: Bob <sip:[email-masked]>;tag=8672349
   To: <sip:[email-masked]>
   Call-ID: [email-masked]
   Contact: <sip:[email-masked]>
   Event: dialog;call-id=[email-masked];to-tag=9fxced76sl
   Expires=0
   Accept: application/dialog-info+xml
   Content-Length: 0

Note that "Event" header contains specific half-dialog information.

This SUBSCRIBE arrives to Alice's UA which is not aware of that dialog. Which 
response should it reply? The flow suggests "481 Call/Transaction doesn't 
exist", but... is it correct?

AFAIK, a 481 should be replied when an *in-dialog* request arrives to an UAS 
which is not aware of that dialog. But in the above case we have an *initial* 
request and the 481 refers to the specific dialog in the "Event" header.

Well, I suggest a possible issue with the above behaviour:

- Alice invites Bob.
- Before sending a provisional response, Bob sends an *initial* SUBSCRIBE to 
Alice with the current half-dialog information in the "Event" header.
- Alice accepts the SUBSCRIBE, replies 200 and later a NOTIFY with the 
specific dialog status.

a)
- After 40 seconds Alice's UA crashes and is restarted (dialog info lost).
- Bob sends a SUBSCRIBE refresh (an in-dialog request).
- That dialog (the SUBSCRIBE dialog) doesn't exist in Alice anymore, so Alice 
replies 481.

b)
- Dialog between Alice and Bob ends because Alice sends a BYE, but before 
Alice receives the BYE and the dialog NOTIFY update, Bob sends a SUBSCRIBE 
refresh (an in-dialog request) for that dialog.
- This SUBSCRIBE arrives to Alice, the SUBSCRIBE request dialog exists but the 
dialog indicated in "Event" header doesn't exist anymore.
- As the above flow suggests, Alice replies 481.

In both cases a) and b), Alice replies 481 but the scenario is completely 
different. The 481 in a) means that the in-dialog SUBSCRIBE belongs to a non 
existing dialog in Alice, while the 481 in b) means that a dialog indicated 
in the Event header doesn't exist.
But there is no way for Bob to realize which is the case a) or b).

The main question is: is 481 the approiate (and valid) reply in the above flow 
(case b)? Is 481 really valid as a reply for an initial request?

-- 
Iñaki Baz Castillo
_______________________________________________
Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Oct 2008 16:33:58 -0400

I agree that 481 seems an unsuitable response in this case.
Its not clear to me what response is best suited. Perhaps 403 or 603.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 25 Oct 2008 23:05:19 +0200

> Its not clear to me what response is best suited. Perhaps 403 or 603.

I suppose 404 is also unappropiate, isn't?

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 26 Oct 2008 00:12:35 +0200

In fact I agree that's a bug -- the SUBSCRIBE is supposed to create a dialog
on its own and it is not denied because of an absent dialog context, but
because Alice has no reason to accept unsolicited subscribes.

Which touches the delicate privacy aspect -- how do we make sure that
the NOTIFY requests disclose only status to a rightful recepient
(i.e., the callee).

-jiri

Paul Kyzivat wrote:
>> Hi, I've a doubt about what should be the correct response for an 
>> initial SUBSCRIBE (Event: dialog) if the indicated dialog doesn't 
>> exist in the recipient of the SUBSCRIBE.
>>
>> This doubt comes after reading the today submitted draft "Dialog Event 
>> foR Identity VErification":
>> In page 14 of this draft there is a flow about a suspicious call 
>> (spoofed From). The flow is correctly displayed using fixed length 
>> typography, if it's not your case refer to page 14 of the draft.
>>
>>
>> So, Bob sends an initial SUBSCRIBE to Alice AoR (the received From uri 
>> in the INVITE F5/F7) with the half-dialog data:
>>
>>    Event: 
>> dialog;call-id=[email-masked];to-tag=9fxced76sl
>>    Expires=0
>> This SUBSCRIBE arrives to Alice's UA which is not aware of that 
>> dialog. Which response should it reply? The flow suggests "481 
>> Call/Transaction doesn't exist", but... is it correct?
>>
>> AFAIK, a 481 should be replied when an *in-dialog* request arrives to 
>> an UAS which is not aware of that dialog. But in the above case we 
>> have an *initial* request and the 481 refers to the specific dialog in 
>> the "Event" header.
>>
>>
>> - Before sending a provisional response, Bob sends an *initial* 
>> SUBSCRIBE to Alice with the current half-dialog information in the 
>> "Event" header.
>> - That dialog (the SUBSCRIBE dialog) doesn't exist in Alice anymore, 
>> so Alice replies 481.
>>
>> b)
>> - Dialog between Alice and Bob ends because Alice sends a BYE, but 
>> before Alice receives the BYE and the dialog NOTIFY update, Bob sends 
>> a SUBSCRIBE refresh (an in-dialog request) for that dialog.
>> - This SUBSCRIBE arrives to Alice, the SUBSCRIBE request dialog exists 
>> but the dialog indicated in "Event" header doesn't exist anymore.
>> In both cases a) and b), Alice replies 481 but the scenario is 
>> completely different. The 481 in a) means that the in-dialog SUBSCRIBE 
>> belongs to a non existing dialog in Alice, while the 481 in b) means 
>> that a dialog indicated in the Event header doesn't exist.
>> The main question is: is 481 the approiate (and valid) reply in the 
>> above flow (case b)? Is 481 really valid as a reply for an initial 
>> request?
>>
>>
>>
>>

---

From: [email-masked]
Date: Tue, 28 Oct 2008 22:36:54 -0400 (EDT)

From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= <[email-masked]>

It's not clear to me reading RFC 4235 that a SUBSCRIBE with an Event
header that specifies a Call-Id that is unknown to the UAS will result
in a failure response.  It may obtain a NOTIFY that lists no dialogs.

But if it does receive an error, 404 seems the most appropriate.

In any case, for the purposes of DERIVE, none of that matters:  Any
failure response to the SUBSCRIBE, or a NOTIFY that does not list the
call in question, results in call rejection.

Dale

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Wed, 29 Oct 2008 10:25:11 +0100

> in a failure response.  It may obtain a NOTIFY that lists no dialogs.

I have the same doubt. The draft suggests "481 Call/Transaction
doesn't exist" but 481 is supposed for in-dialog request not matching
a transaction in the UAS receiving it.

> But if it does receive an error, 404 seems the most appropriate.

Well, now I don't like this code. Note that a SUBSCRIBE's RURI is like:
  SUBSCRIBE sip:[email-masked] SIP/2.0

404 should be replied by domain.org proxy if it doesn't know a local
user called "alice" (480 would be in case it exists but is not
registered now).
So, if the SUBSCRIBE arrives to the UAS and it replies with 404 it
would be strange, wouldn't it?

> call in question, results in call rejection.

But this behaviour would deny calls from devices not supporting RFC
4235 (receiving a SUBSCRIBE Event: dialog).
AFAIK this draft says that if the SUBSCRIBE is replied with 200 then
the dialog exists and identity verified, if 481 then the device
supports RFC 4235 and it's a suspicius call, and for any other failure
route it could mean that the device doesn't support RFC 4235 or any
kind of "protection" in an intermediary proxy. In the last case, the
receptor of the INVITE should choose to accept or deny the call, he
cannot know if the sender is really the From (or if he is not).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Oct 2008 18:09:28 -0500

While 403 would be valid if local policy warrants, my reading of 4235 is 
that an authorized subscriber would start getting NOTIFY messages that 
contain no dialog information. The dialog identifier is treated as a 
filter. The application of that filter to the existing dialogs might be 
an empty set.

/a

Paul Kyzivat wrote:
>> This doubt comes after reading the today submitted draft "Dialog 
>> Event foR Identity VErification":
>>   
>> So, Bob sends an initial SUBSCRIBE to Alice AoR (the received From 
>> uri in the INVITE F5/F7) with the half-dialog data:
>>
>> have an *initial* request and the 481 refers to the specific dialog 
>> in the "Event" header.
>>
>>
>> - Alice accepts the SUBSCRIBE, replies 200 and later a NOTIFY with 
>> the specific dialog status.
>>
>> a)
>> - This SUBSCRIBE arrives to Alice, the SUBSCRIBE request dialog 
>> exists but the dialog indicated in "Event" header doesn't exist anymore.
>> completely different. The 481 in a) means that the in-dialog 
>> SUBSCRIBE belongs to a non existing dialog in Alice, while the 481 in 
>> b) means that a dialog indicated in the Event header doesn't exist.

---

From: [email-masked]
Date: Fri, 31 Oct 2008 13:54:00 -0400 (EDT)

From: "=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=" <[email-masked]>

   > In any case, for the purposes of DERIVE, none of that matters:
   > Any failure response to the SUBSCRIBE, or a NOTIFY that does not
   > list the call in question, results in call rejection.

   But this behaviour would deny calls from devices not supporting
   RFC4235 (receiving a SUBSCRIBE Event: dialog).AFAIK this draft says
   that if the SUBSCRIBE is replied with 200 thenthe dialog exists and
   identity verified, if 481 then the devicesupports RFC 4235 and it's
   a suspicius call, and for any other failureroute it could mean that
   the device doesn't support RFC 4235 or anykind of "protection" in
   an intermediary proxy. In the last case, thereceptor of the INVITE
   should choose to accept or deny the call, hecannot know if the
   sender is really the From (or if he is not).

In my experience, it's very difficult to accurately distinguish
between "authentication mechanism is not supported by the
correspondent" and "authentication mechanism denies the
correspondent's identity".  The only cases where that distinction can
be made accurately are where both ends of the communication
specifically signal the presence/absence of the authentication
mechanism.

In the case of DERIVE, the goal is for the recipient to be able to
authenticate the caller in a large fraction of cases without requiring
the caller to specifically implement a mechanism to do so.  Given the
high variability of SIP implementations, one cannot reliably impute
meanings to failure response codes.

I would expect that many SIP implementations would not handle Event
parameters (filtering) correctly, and would just return all dialogs
present at the UAC.  So the UAS will have to inspect the event body to
see if its dialog is listed.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 31 Oct 2008 17:11:43 -0500

>   sender is really the From (or if he is not).

clearly one needs a Supported option-tag in the initial request to let  
the called party know that it might be reasonable to try to RRC using  
DERIVE.

--
Dean