Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt

From: "Feng Cao \(fcao\)" <[email-masked]>
Date: Wed, 29 Mar 2006 10:22:50 -0800

There are some needs for providing response identity and we had listed
them in the meeting. So far, one of them had received a lot of support
from both some offline discussions and the comments in this list, it is
to "reveal the proxy's identity as the responder for some response
codes, such as provisional, redirect and failure responses." 

The other two needs listed in the meeting are pasted here again for more
feedback. One is to "disclose the response identity for non-dialog
session", the other is to "prevent the identity spoofing as early as
possible". 

________________________________

From: Francois Audet [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 8:55 AM
To: Vijay K. Gurbani
Cc: [email-masked]'; Drage,Keith (Keith)
Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt

My take is that there is no agreement that there is a compelling reason
to do response identity. That's the main issue.

I agree that connected-identity on the other is non-controversial.

Vijay K. Gurbani wrote: 

	Drage, Keith (Keith) wrote:

		(as chair)

	[...]

		We do not plan to make any decision about the
documentation of
		draft-cao-sip-response-identity-00.txt until there is
some consensus
		on the mechanisms proposed and support for moving
forward. At the
		moment there have been no posts in favour or against
achieving that
		consensus, and at the moment all we can assume is that
there is no
		support for solving this problem at all.

	Keith: Is it conceivable to break the milestone into two?  One
provides
	solution for knowing who I have connected with
(connected-identity),
	and the other provides the identity of the intermediary or
endpoint
	who issued provisional and non-2xx responses (could use
response-
	identity as a starting point).
	
	I don't think there is much debate over connected-identity; the
WG
	agrees that this is the way forward on knowing authoritatively
	who a UAC is connected to.  connected-identity, IIRC, only kicks
in
	when the UAS agrees to session establishment (i.e., a 200 OK is
sent
	out).  But what about user agents and intermediaries that issue
non-2xx
	responses?
	
	Ostensibly, there could be some advantage in knowing that an
	intermediary who issued a 3xx is not sending me on a wild
	goose chase.  TLS could be one way to ascertain the identity of
the
	intermediary if I am connected directly (i.e., next hop) to the
	responder.  But what about a chain of TLS proxies where the
responding
	proxy or UAS is a few hops downstream?  In that case,
response-identity
	allows the receiver to know who issued a final response.
	
	So, does the WG see a need to provide a solution for response
identity,
	which could be defined as the identity of an intermediary
issuing a
	1xx response or a non-2xx response, or the identity of an
endpoint
	issuing a non-2xx response?  If so, then maybe the following can
be
	candidate proposals:
	
	1) response-identity.
	2) P-A-I applied to responses.
	3) H-I header (I don't think this works since in H-I it is the
	   UAC or the proxy that sends a request downstream that adds a
	   H-I header.  A UAS echoes the H-I headers, but does not add
	   them pre-emptively, AFAIK).
	4) Others...?
	
	Thanks,
	
	- vijay

________________________________

	_______________________________________________
	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: Shida Schubert <[email-masked]>
Date: Wed, 29 Mar 2006 12:27:23 -0800

Hi Feng;

I don't really know how much of the problem can really be solved here,
and I would like to know because it seems like I am just not getting it.

Proxy non-adjacent to UA sending a response identity alone does not
seem to provide enough information that the responding proxy really
is a valid proxy, meaning that it's not a MitM. Unless you can show that
the request indeed ended up at the proxy responding with the identity,
response-identity alone seems insufficient, may be useful but insufficient.

I personally think H-I, if signaling path is secured(sips or TLS proxy
chain)
may be sufficient.

Regarding your second issue, what kind of non-dialog session might
find the response-identity useful? I just can't seem to imagine a
use-case that's sensible and I am very interested in hearing its usage.

Lastly, I thought about the last issue you brought up about identity
spoofing
and I do see some value in it, as you can probably track the malicious user
who made a plank call more easily if identity header is available. I
guess if
identity header is available you are able to inquire or sue the
responsible domain.

But connected-identity provides the same benefit by providing identity
header
in the request in opposite direction simply at a different stage of the
call.

If it's all about providing this at the call setup time because you
don't want
to exchange any media with the malicious responder, then you can define
a pre-condition where both users need to provide an identity, in which case,
media exchange won't start until connected-identity is provided through an
UPDATE or re-INVITE, upon which UAC or calling proxy can apply its local
policy using the response-identity provided and decide whether to proceed
with the media exchange etc.

Regards
Shida

Feng Cao (fcao) wrote:
> from both some offline discussions and the comments in this list, it
> is to "reveal the proxy's identity as the responder for some response
> The other two needs listed in the meeting are pasted here again for
> more feedback. One is to "disclose the response identity for
> non-dialog session", the other is to "prevent the identity spoofing as
> early as possible".
>
>
> ------------------------------------------------------------------------
> *From:* Francois Audet [mailto:[email-masked]]
> *Sent:* Wednesday, March 29, 2006 8:55 AM
> *To:* Vijay K. Gurbani
> *Cc:* [email-masked]'; Drage,Keith (Keith)
> *Subject:* Re: [Sip] draft-cao-sip-response-identity-00.txt
>
>>> We do not plan to make any decision about the documentation of
>>> draft-cao-sip-response-identity-00.txt until there is some consensus
>>> on the mechanisms proposed and support for moving forward. At the
>>> moment there have been no posts in favour or against achieving that
>>> consensus, and at the moment all we can assume is that there is no
>> Keith: Is it conceivable to break the milestone into two?  One provides
>> solution for knowing who I have connected with (connected-identity),
>> and the other provides the identity of the intermediary or endpoint
>> who issued provisional and non-2xx responses (could use response-
>> I don't think there is much debate over connected-identity; the WG
>> who a UAC is connected to.  connected-identity, IIRC, only kicks in
>> when the UAS agrees to session establishment (i.e., a 200 OK is sent
>> out).  But what about user agents and intermediaries that issue non-2xx
>> responses?
>>
>> goose chase.  TLS could be one way to ascertain the identity of the
>> responder.  But what about a chain of TLS proxies where the responding
>> proxy or UAS is a few hops downstream?  In that case, response-identity
>> So, does the WG see a need to provide a solution for response identity,
>> which could be defined as the identity of an intermediary issuing a
>> 1xx response or a non-2xx response, or the identity of an endpoint
>> issuing a non-2xx response?  If so, then maybe the following can be
>> candidate proposals:
>>
>> 1) response-identity.
>> ------------------------------------------------------------------------
>>
> ------------------------------------------------------------------------
>