[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] MSRP: Contributor ID

Sorry for delayed response - I've been on vacation, but am now back.

Orit Levin wrote: 
Paul,
The answer to "why" in each of the cases relates to the fact that
different cases belong to same architecture/possible deployment. Even
when you see a solution to one case - you are unintentionally missing
another unless you go through the exercise of defining the full
conferencing architecture.

Instead, if we step back and try to look at the problem from the top,
CPIM is a simple means for peer-to-peer private communications with
non-trusted intermediates (e.g. GW, MCUs) potentially present in the
middle. Using CPIM for communications between users and the
intermediates themselves (and still being able to use CPIM for what it
had been designed for) without defining standard ubiquitous means for
distinguishing between the cases - is close to impossible.

I'm still not convinced of why the recipient needs to be able to distinguish the cases.

If a message is received, it could have:
- no indication of source. All that is known is the identification
  of the other end of the signaling path.

- it could have a single CPIM wrapper, unsigned, unencrypted,
  that identifies the source. The recipient doesn't know if this
  came from the actual sender, or from some intermediary. But
  does it matter? In either case it can't be authenticated.

- it could have a single CPIM wrapper, signed by the actual
  sender.

- it could have a single CPIM wrapper, signed by the mixer.

- it could have two CPIM wrappers, one signed by the sender,
  one signed by the mixer.

In all of the signed cases, what is the value in knowing via the protocol whether a signature came from the mixer or the sender? What is really important is who is signing and whether you can authenticate the signature. If you have multiple signatures that you trust, and the corresponding CPIM wrappers disagree about who the sender is, then you have to decide which to trust, or else just display them both. If you want to pick one, does it really help to know whether it came from the mixer or not?

On the RTP note, RTP is different from MSRP in many aspects: 

True. The analogy can only be stretched so far.

- RTP doesn't use CPIM and as a result doesn't have this problem to
start from :-)


True. That of course wasn't the analogy I was considering.

My point was that in a conference, the sender uses RTP/RTCP to talk to the mixer, including its capabilities for identifying the sender. Then the mixer uses RTP/RTCP to talk to the recipient, again using its capabilities for identifying the sender. There isn't one way for the sender to identify itself to the recipient and a different way for the mixer to represent its notion of the sender to the recipient.

An analogous same state of affairs could be achieved using CPIM, if the mixer refuses to accept encrypted messages that it cannot decrypt. It could then receive messages, remove any incoming CPIM wrapper, then add and sign a CPIM wrapper for the recipient.

- SSRC is used as a stream identifier only. In the core RTP, there is no
multiplexing inside the UDP connection (which is 1-to-1 with the RTP
session). In MSRP, the from-path value is used as the part of the "MSRP
session identifier" for multiplexing inside a TCP tunnel.


This is all true. But I don't see how it affects the discussion at hand.

- in addition to the RTP "mixer" mode being implemented today, RTP also
defines the "translator" mode - which is much closer to what happening
in IM conferencing case. It this mode, the original SSRC is PRESERVED by
translators (and the CSRC list is not created because it doesn't have
any meaning at all).

This would be analogous to an MSRP mixer passing CPIM messages thru unmodified. Note that the description of translator mode in RFC 3550 mentions that when it is used the recipient can't tell that a translator is present.

Note that RTP doesn't ever address the case where the sender doesn't provide CNAME info, or when it is wrong. Our case in MSRP of having the focus provide identification of the sender when the sender didn't provide that information is functionality not considered in RTP.

> As it was stated earlier, voice and video 
conferencing vendors got away with it only because the user can guess
the source by his/her voice or video. This doesn't work for IM unless an
advanced conferencing protocol (e.g. XCON) is being used by ALL
participants.

Agreed that it is more important to receive sender identification with MSRP than it is with RTP. But then we are free to work out what the extended needs are.

	Paul

Orit.


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Thursday, August 26, 2004 12:00 PM
To: Orit Levin
Cc: Ben Campbell; Adam Roach; Alan Johnston; simple at ietf.org
Subject: Re: [Simple] MSRP: Contributor ID



Orit Levin wrote:



If
the message already had a cpim wrapper, then the focus

could choose to 

leave it alone, or put it inside yet another wrapper.
(You can have nested cpim wrappers.)


To accommodate the end-to-end encrypted CPIM, it will need to be something like:
If the message already had a cpim wrapper and the destination is conference-aware, then the focus puts it inside yet another clear wrapper (that is in order to provide mapping to conferencing extensions).
If the message already had a cpim wrapper and the destination is conference-unaware (e.g. doesn't use XCON) leave it alone

(that is in

order to not confuse the receiving client with conferencing information vs. peer-to-peer information). 

>

This is VERY DIFFERENT from the existing today conferencing architecture where the focus logic is NOT dependant on the participant's ability to understand or actively support 

conferencing extensions and protocols.

I don't understand why you are splitting out different behaviors for conference aware and unaware participants.

If the focus wants to ensure that messages are properly identified as to source, then it will either have to add a CPIM wrapper, or else inspect and approve one that is already present. If the message is encrypted e2e so that the focus can't decrypt, then it doesn't matter whether the encrypted body is CPIM or not. Either way the focus will have to wrap the encrypted body in a new CPIM wrapper.

It can only avoid this if it doesn't feel it is necessary to identify the message sender. It will be up to the conference arch to decide about that. Maybe it will depend on whether the recipient is conference aware, maybe not.


Yet "MY MAJOR PROBLEM" with using CPIM wrapper for

conferencing/focus

can be summarised as following:
There is no (well-defined simple) way in the CPIM header to distinguish whether a particular CPIM is being used for

intermediate

(e.g. focus,
GW) vs. for peer-to-peer needs. A user may have very

different privacy

policies regarding each. In the case of conference-unaware

user - the

UA will not even have the ability to distinguish between 

the two cases.

Why should there be? there isn't any way to do this for RTP/RTCP. There isn't any ability to have both kinds. And it is up to the mixer whether it preserves the IDs provided by the sender or puts in artificial ones. The recipient can't tell which is the case.


Which identity will the user put in the requested CPIM header? The private (for peer-to-peer) or the public for the focus use? How the receiving participant (which can be conference unaware as

well) will

undertsand what kind of identity he is looking at?

If there are multiple unsigned and unencrypted identities, then the recipient should probably display them all, or maybe none of them if it is untrusting. If some or all of the identities are signed, then it could choose to only display ones signed by somebody it trusts.

	Paul




_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple



_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple