Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01

From: "Elwell, John" <[email-masked]>
Date: Wed, 22 Mar 2006 18:44:41 +0000

Rocky,

The connected-identity draft already gives two examples why a mid-dialog
change would be needed: PSTN gateway and B2BUA.

We could define a new header field for response identity if this can be
justified, but it would not be secure. I think the consensus yesterday was
to move forward with connected-identity and consider separately whether
response identity is achievable in a way that is secure as well as adding
some value in certain use cases.

John

> -----Original Message-----
> From: Rocky Wang [mailto:[email-masked]] 
> Sent: 22 March 2006 14:44
> To: Elwell, John; [email-masked]
> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and 
> draft-elwell-sip-connected-identity-01
> 
>  As my opinion, they two just need take the responser 
> identifier in the
> response messages. We must consider and resolve all the 
> problem include the
> security problems in both cases.
> If you want to indicate a change of party mid-dialog, you can use some
> mid-dialog method to do it, as I considered, just like UPDATE 
> and re-INVITE.
> That's not so difficult in use of exist mechanism. But can 
> you please give
> me an application case of the usage of mid-dialog entity identifier
> indication.
> 
> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, March 21, 2006 11:44 PM
> To: Rocky Wang; [email-masked]
> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and
> draft-elwell-sip-connected-identity-01
> 
> Rocky,
> 
> The connected-identity draft is not a subset of the response 
> identity draft.
> The response identity draft cannot be used to indicate a 
> change of party
> mid-dialog.
> 
> I don't think we can merge them. There was no consensus on 
> the response
> identity draft. The following views have been expressed:
> - that it does not provide any benefit;
> - that the response identity problem cannot be solved, and 
> that the approach
> taken in the connected-identity draft is the best that can be 
> achieved.
> 
> If and when there is consensus on a response identity 
> solution, then we
> could consider whether it would be appropriate to merge the 
> two, but that is
> not the case at present.
> 
> John
> 
> > -----Original Message-----
> > From: Rocky Wang [mailto:[email-masked]]
> > Sent: 21 March 2006 19:50
> > To: [email-masked]
> > Subject: [Sip] draft-cao-sip-response-identity-00 and
> > draft-elwell-sip-connected-identity-01
> > 
> > 
> > Both of draft-cao-sip-response-identity-00 and
> > draft-elwell-sip-connected-identity-01 have been disscussed 
> in today's 
> > SIP session. I found they two can be merged into one.
> > The first one is a common requirement to return back the identity 
> > identifier. It can be used in both successful responses, 
> but also in 
> > provisiional, redirect and failure responses, but the 2nd 
> one is just 
> > used for 18X and 2XX response for INVITE (maybe also some 
> other type 
> > requests).
> > As I considered, the 2nd one is just a sub-set case of the 
> first one. 
> > Can merge the 2nd one into the 1st one? Or merge the requirement of 
> > the 1st into the last.
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 

_______________________________________________
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: Feng Cao <[email-masked]>
Date: Wed, 22 Mar 2006 13:01:12 -0800 (PST)

Because connected-id is revealed in the mid-dialog, there are some 
scenarios that are not covered by connected-identity draft.

In general, I agreed with Rocky that the mid-dialog update can be
easily convered or embeded into the sip identity draft by Jon and
Cullen. I don't see the need of another new draft for it.

Some useful scenarios for response identity inside response messages
had been listed for discussion:
1. disclose the response identity for non-dialog session.
2. reveal the proxy's identity as the responder for some response
    codes, such as provisiional, redirect and failure responses.
    This will help the callers to make decisions.
3. prevent the identity spoofing as early as possible. In some cases,
    it is too late to be notifies of the response identity after the
    dialogs are established.

--Feng

---

From: Rocky Wang <[email-masked]>
Date: Wed, 22 Mar 2006 17:41:23 -0600

I agree with you that there are some requirements to convey the changed
identifier. But I think UPDATE and re-INVITE can be used to do so, that is
no need to create a 2nd solution.
Apart from the mid-dialog requiements, the Connect-URI can be considered as
a sub-set of the response identifier. Today we are discussing about
conveying the connected URI that return the response, tomorrow, maybe we
must re-consider how to convey the identifier which return responses and
then we must do the same thing again, including the security and some other
problems.
What I want to say is that the two drafts can be merged easily from the
requirement and expected solution aspects because they are overlapped with
each other, and we should do so as my owner opinion.

Rocky Wang

> Sent: Wednesday, March 22, 2006 12:45 PM
> The connected-identity draft already gives two examples why a 
> mid-dialog change would be needed: PSTN gateway and B2BUA.
> 
> We could define a new header field for response identity if 
> this can be justified, but it would not be secure. I think 
> the consensus yesterday was to move forward with 
> connected-identity and consider separately whether response 
> identity is achievable in a way that is secure as well as 
> adding some value in certain use cases.
> 
> John
>  
> 
> >  As my opinion, they two just need take the responser identifier in 
> > the response messages. We must consider and resolve all the problem 
> > include the security problems in both cases.
> > mid-dialog method to do it, as I considered, just like UPDATE and 
> > re-INVITE.
> you please 
> > give me an application case of the usage of mid-dialog entity 
> > identifier indication.
> > 
> > The connected-identity draft is not a subset of the 
> response identity 
> > draft.
> > The response identity draft cannot be used to indicate a change of 
> > party mid-dialog.
> > 
> > I don't think we can merge them. There was no consensus on the 
> > response identity draft. The following views have been expressed:
> > - that the response identity problem cannot be solved, and that the 
> > approach taken in the connected-identity draft is the best 
> that can be 
> > achieved.
> > 
> solution, then 
> > we could consider whether it would be appropriate to merge the two, 
> > but that is not the case at present.
> > 
> > John
> >

---

From: Shida Schubert <[email-masked]>
Date: Wed, 22 Mar 2006 17:27:51 -0800

Hi Rocky;

 Why do you want the response identity so bad?
 - As  I understand there are two issues, response identity is trying to 
solve.
   Issue 1. Who am I really connected to and is it really who it claims 
it is?
    - Connected Identity solves this problem by allowing the changes in 
 From header
       field and re-using the SIP-Identity spec. The Connected-Identity 
spec is nice
       because it reuses what's already there and does not introduce any 
new header for
       indicating identity. And inherit all the nice traits identity 
header provides such as
       integrity etc.
   - Response Identity tries to provide the same thing by introducing 
few new headers
     which clutters the header with more Identity related information. 
Beside there are
     few issues with how one should trust the response-identity(Proxy 
unable to authorize
     the response etc.).

  Issue 2. Am I connected to foo as a result of routing decision based 
on my INVITE?
   - Can't really solve the issue with neither of the solution described 
above.
 
   Issue 2 can't be solved by neither of the solution and Issue 1 can be 
solved with
   Connected Identity without adding any extra identity related header. 
So I personally
   don't know why you are so persistent with adopting them both? I think
   Connected-Identity alone satisfies what the WG wants, but I could be 
completely
   wrong.

   As for other reason why I don't think they should merge, currently 
they propose two
   completely different solution to address the same problem yet at 
different timing.
 
  And let's not forget, merging the work would create dependency on each 
spec and
   results in creating a delays in overall progress. I have been hearing 
that WG wants to
   resolve Issue 1, in which case delay due to the merge is likely to be 
unacceptable.
 
 Regards
  Shida Schubert

Rocky Wang wrote:
>>> If you want to indicate a change of party mid-dialog, you 
>>>       
>> can use some 
>>     
>>>> Can merge the 2nd one into the 1st one? Or merge the 
>>>>         
>> requirement of 
>>     
>>>> the 1st into the last.
>>>>
>>>>
>>>>

---

From: Feng Cao <[email-masked]>
Date: Thu, 23 Mar 2006 08:17:11 -0800 (PST)

Hi Shida,

Your comments reflected many offline discussions we had with
some folks. They can be summarized into the following three
questions. Then the logic relationships among them can be understood
and the scope can be defined.

Q1. provide the mechanism to disclose response identity
    (and integrity protection) in all call scenarios.

    That is the exact scope our draft tried to address. As you pointed out,
    there are issues about it. Please see the following questions.

Q2. provide the secure authentication and authorization mechanism
     for response

    We did realize this problem. We submitted another draft
    to address this question, it is available at 
http://www.ietf.org/internet-drafts/draft-cao-sip-response-auth-01.txt.
    We had received some feedbacks about it outside this list.

    The consensus with some folks before the meeting is to discuss Q1 first
    and see if we can make progress. I think it is reasonable to separate
    Q1 and Q2, as the scopes and the solutions are different.

    Frankly, I expected this question to be raised, as you and
    a few other folks did either in this list and in private discussions.

Q3. provide the mechanism to understand why that responder is reached.

    This is a very interesting (and hard) problem about SIP request
    deliverary. First, this should be out of scope about response
    identity, even though the answer can be helpful. Second, it is not
    among SIP WG deliverables?

Hope this summary can be helpful for further discussions.

Thanks,

--Feng

On Wed, 22 Mar 2006, Shida Schubert wrote:
>  Issue 1. Who am I really connected to and is it really who it claims it is?
>    - Connected Identity solves this problem by allowing the changes in From 
> header
>      field and re-using the SIP-Identity spec. The Connected-Identity spec 
> is nice
>      because it reuses what's already there and does not introduce any new 
> header for
>      indicating identity. And inherit all the nice traits identity header 
> provides such as
>       integrity etc.
>  - Response Identity tries to provide the same thing by introducing few new 
> headers
>    which clutters the header with more Identity related information. Beside 
> there are
>    few issues with how one should trust the response-identity(Proxy unable 
> to authorize
>     the response etc.).
>
> Issue 2. Am I connected to foo as a result of routing decision based on my 
> INVITE?
>  Connected Identity without adding any extra identity related header. So I 
> personally
>  As for other reason why I don't think they should merge, currently they 
> propose two
>  completely different solution to address the same problem yet at different 
> timing.
> 
> And let's not forget, merging the work would create dependency on each spec 
> and
>  results in creating a delays in overall progress. I have been hearing that 
> WG wants to
>> >  From: Elwell, John [mailto:[email-masked]] Sent: Wednesday, 
>> >  March 22, 2006 12:45 PM
>> >  justified, but it would not be secure. I think the consensus yesterday 
>> >  was to move forward with connected-identity and consider separately 
>> >  whether response identity is achievable in a way that is secure as well 
>> >  as adding some value in certain use cases.
>> > 
>> >  John
>> > 
>> > 
>> > 
>> > >  As my opinion, they two just need take the responser identifier in the 
>> > >  response messages. We must consider and resolve all the problem

---

From: Shida Schubert <[email-masked]>
Date: Thu, 23 Mar 2006 08:30:35 -0800

Hi Feng;

 Comments inline..

>    there are issues about it. Please see the following questions.
 I understand.
>    a few other folks did either in this list and in private discussions.
 I read the draft, and it seems like you are re-defining TLS.
>    among SIP WG deliverables?
 Okay I thought this was addressed as one of the problem space your
draft is trying to solve. I guess, I miss read the draft. My apology.

 Regards
  Shida Schubert

>> - As  I understand there are two issues, response identity is trying 
>> to solve.
>>    - Connected Identity solves this problem by allowing the changes 
>> in From header
>>      because it reuses what's already there and does not introduce 
>> any new header for
>>  - Can't really solve the issue with neither of the solution 
>> described above.
>>
>>  Issue 2 can't be solved by neither of the solution and Issue 1 can 
>> be solved with
>>   Connected-Identity alone satisfies what the WG wants, but I could 
>> be completely
>>   wrong.
>>
>> And let's not forget, merging the work would create dependency on 
>> each spec and
>>  results in creating a delays in overall progress. I have been 
>> hearing that WG wants to
>>  resolve Issue 1, in which case delay due to the merge is likely to 
>> be unacceptable.
>>
>> Regards
>>  Shida Schubert
>>
>> Rocky Wang wrote:
>>>  Apart from the mid-dialog requiements, the Connect-URI can be 
>>> considered
>>>  as
>>> >  From: Elwell, John [mailto:[email-masked]] Sent: 
>>> Wednesday, >  March 22, 2006 12:45 PM
>>> >  Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >  
>>> mid-dialog >  change would be needed: PSTN gateway and B2BUA.
>>> this can be >  justified, but it would not be secure. I think the 
>>> consensus yesterday >  was to move forward with connected-identity 
>>> and consider separately >  whether response identity is achievable 
>>> in a way that is secure as well >  as adding some value in certain 
>>> use cases.
>>> > >  John
>>> identifier in the > >  response messages. We must consider and 
>>> resolve all the problem > >  include the security problems in both 
>>> cases.
>>> > >  If you want to indicate a change of party mid-dialog, you > > 
>>> >  can use some > > >  mid-dialog method to do it, as I considered, 
>>> just like UPDATE and > >  re-INVITE.
>>> > >  That's not so difficult in use of exist mechanism. But can > > 
>>> >  you please > > >  give me an application case of the usage of 
>>> mid-dialog entity > >  identifier indication.
>>> > > > >  The connected-identity draft is not a subset of the > > >  
>>> response identity > > >  draft.
>>> > >  The response identity draft cannot be used to indicate a change 
>>> of > >  party mid-dialog.
>>> the > >  response identity draft. The following views have been 
>>> expressed:
>>> > >  - that the response identity problem cannot be solved, and that 
>>> the > >  approach taken in the connected-identity draft is the best 
>>> > > >  that can be > > >  achieved.
>>> > > > >  If and when there is consensus on a response identity > > 
>>> >  solution, then > > >  we could consider whether it would be 
>>> appropriate to merge the two, > >  but that is not the case at present.
>>> > > > >  John
>>> > > >  The first one is a common requirement to return back the 
>>> identity > > >  identifier. It can be used in both successful 
>>> responses,
>>> > > > > >  but also in
>>> > > > > >  first one. > > > > >  Can merge the 2nd one into the 1st 
>>> one? Or merge the > > > >  requirement of > > > >  the 1st into the 
>>> last.
>>> > > > > > > > > >
>>> > > >  [email-masked] for questions on current sip 
>>> Use > > >  [email-masked] for new developments on the application 
>>> of sip
>>> > > > > > > > >
>>>
>>>

---

From: "Rocky Wang" <[email-masked]>
Date: Sat, 25 Mar 2006 21:00:19 -0600

I suggest to merge the two draft together does not mean I want you to accept
cao's solution. Bur from the requirement viewpoint, I suggest we should do
so.
And see below inline, please:

> From: [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 7:28 PM
> To: Rocky Wang
> Cc: 'Elwell, John'; [email-masked]
> Subject: Re: [Sip] draft-cao-sip-response-identity-00 
> anddraft-elwell-sip-connected-identity-01
> 

>  Why do you want the response identity so bad?

Really I don't want the response identify BAD!
When you read the documents as the session order, you will find that the
requirements are overlapped and it is easy for anybody to get a conclusion
that we should merge them into one. That is, anyone goes forward a little,
it will be esay to conver the requirement in another.
And it is nature that we can use the UPDATE and re-INVITE to update the
local identity identifier. I don't anybody hold another opinion on this. Why
we need an extension header or mechanism for this part of requirement?
Just like Cullen Jennings said in IETF64, the implementator will fall into
confusion because he don't know where it should get the peer identifier.
There is no any problem for anyone using his owner mechanism, but what about
for others? It already goes so difficult till now and I can't imagine what
it will be tomorrow. For each one, it looks like simple enough, but if you
consider them all together, how complex it is now!

>  - As  I understand there are two issues, response identity 
> is trying to solve.
>     - Connected Identity solves this problem by allowing the 
> changes in  From header
>        field and re-using the SIP-Identity spec. The 
> Connected-Identity spec is nice
>        because it reuses what's already there and does not 
> introduce any new header for
>        indicating identity. And inherit all the nice traits 
> identity header provides such as
>        integrity etc.
>    - Response Identity tries to provide the same thing by 
> introducing few new headers
>      few issues with how one should trust the 
> response-identity(Proxy unable to authorize
>      the response etc.).

I really don't want to deny your extension at all, but we should consider
the reqirements together but not seperated. It is the same thing for your
two drafts but different case, one is for successful calls and another
include failure flows as well. I would like to know what's your opinion.
I also know that the meeting has already get a consensus for your draft, but
I want to have a discussion on if it is possible put the provisional,
successful, redirecting and failure cases together from the ML.

> 
>   Issue 2. Am I connected to foo as a result of routing 
> decision based on my INVITE?
>    - Can't really solve the issue with neither of the 
> solution described above.
>  
>    Issue 2 can't be solved by neither of the solution and 
> Issue 1 can be solved with
>    Connected-Identity alone satisfies what the WG wants, but 
> I could be completely
>    wrong.

I have expressed my opinion above already.

> 
>    As for other reason why I don't think they should merge, 
> currently they propose two
>    completely different solution to address the same problem 
> yet at different timing.

Firstly, the requirements in the two drafts are really can be merged. And
for the solution, we should have a more discussion on it. No body wants to
accept two mechanisms to resolve the same problem in these two different
simillar cases, I think.
I have consensus with your solution. I would like choose change the To-URI
if both UAC and UAS support to change the From and To URI, otherwise maybe
P-Asserted-Identity header is fit on this.
I suggest to merge the two draft together does not mean I want you to accept
cao's solution. Bur from the requirement viewpoint, I suggest we should do
so.

>  
>   And let's not forget, merging the work would create 
> dependency on each spec and
>    results in creating a delays in overall progress. I have 
> been hearing that WG wants to
>    resolve Issue 1, in which case delay due to the merge is 
> likely to be unacceptable.

Why it is impossible to merge the requirement togher?

>  
>  Regards
>   Shida Schubert
> 
> Rocky Wang wrote:
> > I agree with you that there are some requirements to convey the 
> > changed identifier. But I think UPDATE and re-INVITE can be 
> used to do 
> > so, that is no need to create a 2nd solution.
> > considered as a sub-set of the response identifier. Today we are 
> > discussing about conveying the connected URI that return 
> the response, 
> > tomorrow, maybe we must re-consider how to convey the 
> identifier which 
> > return responses and then we must do the same thing again, 
> including 
> > the security and some other problems.
> > What I want to say is that the two drafts can be merged easily from 
> > the requirement and expected solution aspects because they are 
> > overlapped with each other, and we should do so as my owner opinion.
> >
> > Rocky Wang
> >
> >
> >   
> >> We could define a new header field for response identity 
> if this can 
> >> be justified, but it would not be secure. I think the consensus 
> >> yesterday was to move forward with connected-identity and consider 
> >> separately whether response identity is achievable in a 
> way that is 
> >> secure as well as adding some value in certain use cases.
> >>
> >> John
> >>  
> >>
> >>     
> identifier in 
> change of 
> identity