Subject: [Sip] update to target-dialog

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Oct 2005 01:28:13 -0400

I just submitted a revision to the target-dialog spec. Until it appears, 
you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-02.txt

The changes are:

* More text on the importance of cryptographic identifiers for dialog IDs
in order to prevent attacks

* removed NOTIFY as an example dialog-forming request; while it is
one, its confusing to be listed here since target-dialog isn't used in
NOTIFY

* fixed bug in example where 'user agent C' needed to be 'user agent
B'

* generalized the overview; it was written explicitly with REFER, but
target-dialog is more general purpose

* added IANA registry of header field parameters

There are no open issues. I believe this document is ready to go.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 23 Oct 2005 23:50:51 +0200

Jonathan,

It seems to me that In-Reply-To (RFC3261) is very similar to the new 
Target-Dialog header proposed in the draft. Perhaps this would merit some 
discussion (on this list and/or in the draft), in particular:

- syntax is very similar, except that In-Reply-To does not allow parameters
- For In-Reply-To, RFC3261 explicitly states that "This field is not a 
substitute for request authentication"
- Is Target-Dialog to be used also for the use case for In-Reply-To 
mentioned in RFC3261 (return calls)? In that case there is no existing 
dialog, but there are similarities

Regards,

Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Oct 2005 00:35:26 -0400

I hadnt considered any relationship with In-Reply-To, this is an 
interesting question. In-Reply-To has seen little to no usage to date, 
AFAIK. Its original intent was quite literally for calling someone back 
later. So, if A calls B, B will have a call log that records it. When B 
calls A back, A will know that this is a call back. Presumably the UA 
would alert the user that this was a callback from a specific call made 
earlier, so the user could decide to accept or reject.

As such, I do not think that the In-Reply-To is a substitiute or 
appropriate vehicle for what we want to do with target-dialog. THe 
reasons are:

1. In-Reply-To references a past call originated by the recipient of 
In-Reply-To. Target-Dialog references a current dialog, and the 
direction of initiation is not relevant

2. In-Reply-To has just a call-id. We need an entire dialog ID.

3. In-Reply-To is meant for human consumption, Target-Dialog, for an 
automata.

4. In-Reply-To implies cause and effect; i.e., this new request is 
BECAUSE of the request you sent me with this call-id. There is no cause 
and effect here, merely a reference for authorization purposes

So, though close, they're not the same. I'm not sure how important this 
is in the draft, since its more of a question of design choice and/or 
relationship with other similar headers. Nice FYI, but won't impact interop.

Thanks,
Jonathan R.

Jeroen van Bemmel wrote:

> Target-Dialog header proposed in the draft. Perhaps this would merit 
> some discussion (on this list and/or in the draft), in particular:
> 
> ----- Original Message ----- From: "Jonathan Rosenberg" <[email-masked]>
>> I just submitted a revision to the target-dialog spec. Until it 
>> appears, you can pick it up at:
>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 26 Oct 2005 09:16:34 +0200

Jonathan,

I agree with your assesment. Syntax-wise Target-Dialog is a superset of 
In-Reply-To, so I was thinking more in terms of Target-Dialog making 
In-Reply-To obsolete (and not in terms of substituting TD with IRT). In 
particular because I think the In-Reply-To use case (call back) could use 
the authorization which TD provides (and matching on the entire dialog-id 
instead of only the call-id IRT provides). Issue is then that there is no 
'current' dialog in that case.

However, your answer does clarify (for me at least) the design intentions of 
TD, perhaps including some of this information in the draft helps 
understandability

More responses inline

Thanks,

Jeroen

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Wednesday, October 26, 2005 6:35 AM
Subject: Re: [Sip] update to target-dialog

>calls A back, A will know that this is a call back. Presumably the UA would 
>alert the user that this was a callback from a specific call made earlier, 
>so the user could decide to accept or reject.
>
> appropriate vehicle for what we want to do with target-dialog. THe reasons 
> are:
>
> In-Reply-To. Target-Dialog references a current dialog, and the direction 
> of initiation is not relevant
>

How strong is this "current dialog" requirement? Section 4 currently states 
that when no match is found (i.e. no current dialog), the header MUST be 
ignored.

For both example use-cases mentioned (application interaction and dialog 
tracking), it seems that in case of no match the purpose of the request is 
lost. I can see value in specifying that either:
1) When no match is found, the request containing the TD header MUST be 
replied to with an error response (e.g. 481 Dialog does not exist)
2) OR the sender can include a parameter / flag indicating its preference in 
case of no-match (to allow for valid use cases with no current dialog)

I think in particular for the application interaction example this would 
improve the user experience (e.g. when a URL to an interface is sent, and 
that interface is no longer relevant when the call has ended). This is 
related to the TD header but does go beyond the intended purpose of 
authorization

> 3. In-Reply-To is meant for human consumption, Target-Dialog, for an 

I would think that both are for automata, a user agent could use the IRT 
call-id as index into its call-log and bring up more details on the call 
(e.g. "You called this party on this and that date/time, there was no 
answer")

> 4. In-Reply-To implies cause and effect; i.e., this new request is BECAUSE 
> of the request you sent me with this call-id. There is no cause and effect 
> here, merely a reference for authorization purposes
>

5. There can be multiple In-Reply-To headers in a request (although that has 
probably seen even less usage than the single header case)

>
> So, though close, they're not the same. I'm not sure how important this is 
> in the draft, since its more of a question of design choice and/or 

I was triggered by the syntactic similarity, and then started wondering 
about functional overlap. Based on this information I now believe that they 
are disjunct in purpose; the only point left is whether there are use cases 
(like call back) where authorization is desirable too, although there is no 
"current" dialog. Is the "current" aspect nescessary or perhaps too 
restrictive, and should TD applicability be extended to work for non-current 
dialogs too?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Oct 2005 18:01:23 -0400

Jeroen van Bemmel wrote:

> In-Reply-To obsolete (and not in terms of substituting TD with IRT).

I'd rather not. I think they really have different semantics.

> In 
> particular because I think the In-Reply-To use case (call back) could 
> use the authorization which TD provides (and matching on the entire 
> dialog-id instead of only the call-id IRT provides). Issue is then that 
> there is no 'current' dialog in that case.

But they are menat for different consumption. Target-Dialog is really 
meant for automata to authorize a request based on security properties. 
In-Reply-To is really for rendering to a human, so they can know that 
this call was a consequence of a previous call attempt (which may have 
never even resulted in a dialog).

> 
> However, your answer does clarify (for me at least) the design 
> intentions of TD, perhaps including some of this information in the 
> draft helps understandability

I could add some text to clarify; I'd really rather do that in a rev 
that comes out after IETF LC...

> How strong is this "current dialog" requirement? Section 4 currently 
> states that when no match is found (i.e. no current dialog), the header 
> MUST be ignored.

Well, as you say, the MUST requirement makes it clear that it is about 
the current dialog.

> tracking), it seems that in case of no match the purpose of the request 
> is lost. I can see value in specifying that either:

481 is not appropriate since there isnt yet a dialog. The point of 
ignoring the target-dialog is that you'd proceed as if the originator 
didn't know about the dialog, and let authorization happen by other 
means. In most cases, my assumption is that the request would not be 
authorized, and result in a 403.

> 2) OR the sender can include a parameter / flag indicating its 
> preference in case of no-match (to allow for valid use cases with no 
> current dialog)

I think the UAS has to decide what happens, not be dictated by UAC.

> improve the user experience (e.g. when a URL to an interface is sent, 
> and that interface is no longer relevant when the call has ended). This 
> is related to the TD header but does go beyond the intended purpose of 
> authorization

In most cases, the thing that is requested the interaction with the UA 
will know that the dialog has gone away..

> (e.g. "You called this party on this and that date/time, there was no 

True, but its still ultimately to render something. Its a UI hint, no more.

>> BECAUSE of the request you sent me with this call-id. There is no 
>> cause and effect here, merely a reference for authorization purposes
>>
> 
> 5. There can be multiple In-Reply-To headers in a request (although that 
> has probably seen even less usage than the single header case)

Well, there is no non-negative integer less than zero, so its the same 
either way ;)

> 
>>
>> So, though close, they're not the same. I'm not sure how important 
>> this is in the draft, since its more of a question of design choice 
>> and/or relationship with other similar headers. Nice FYI, but won't 
>> impact interop.
>>
> 
> about functional overlap. Based on this information I now believe that 
> they are disjunct in purpose; the only point left is whether there are 
> use cases (like call back) where authorization is desirable too, 
> although there is no "current" dialog. Is the "current" aspect 
> nescessary or perhaps too restrictive, and should TD applicability be 
> extended to work for non-current dialogs too?

I would rather not. Target-dialog has a pretty specific scope, and 
expanding it to include the functions of In-Reply-To is not something I 
see a need to do.

-Jonathan R.