Subject: RE: [Simple] MSRP: Contributor ID

From: [email-masked]
Date: Wed, 11 Aug 2004 17:29:49 +0300

There is a requirement that a chunk should not contain a body greater than 12000 bytes in size unless it is interruptible. If a mixer is adding extra CPIM headers to those chunks making them greater than 1200 bytes, then the mixer needs to re-chunk.

Or have I not thought this through?

I'm not advocating one over the other yet, I'm just trying to collect data to base the decision on.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 11.August.2004 17:15
> To: Rohan Mahy
> Cc: Cullen Jennings; Robert Sparks; Khartabil Hisham
> (Nokia-TP-MSW/Helsinki); Adam Roach; Simple WG; Orit Levin; Ben
> Campbell; Chris Boulton
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> 
> Rohan,
> 
> Thanks for filling in details. You do help make the fundamental point 
> that CPIM is not substantially more complex than an new 
> header for this 
> purpose. Most of the issues that Ben brought up are the same 
> for both. 
> So I continue to think the decision on which way to go should 
> be based 
> on other criteria.
> 
> The numerous extra cases you bring up are interesting. An important 
> question is how the mixer in fact determines what strategy to 
> take with 
> a given message?
> 
> If a message is signed and not encrypted then I guess there 
> is never any 
> reason for the focus to remove that signature - it can just 
> add another 
> one if it wishes.
> 
> But if a message is encrypted, and the mixer knows how to 
> decrypt it, it 
> needs to decide if it should do so (because some or all the the 
> participants may not be able to decrypt it), or leave it 
> alone. And then 
> it needs to decide if it should re-encrypt it.
> 
> Some of this is simply policy, but there probably need to be some 
> standards for how this should be done if there is to be any prayer of 
> interoperability.
> 
> 	Paul
> 
> Rohan Mahy wrote:
> > Paul,
> > 
> > I am not arguing for using CPIM.  I actually feel its kind 
> of ugly, but 
> > in the interest of describing what you need to do to use 
> CPIM, I think 
> > you missed a few cases.  I believe there are 2 axes here 
> (signature, and 
> > crypto)
> > 
> > 1. Unsigned
> > 2. Signed by the participant
> > 3. Signed by the focus
> > 4. Signed by both the participant and the focus
> > 
> > A. Unencrypted
> > B. Encrypted with a group key to whole conference
> > C. Encrypted to Focus, Re-encrypted to Target Participant
> > 
> > On the signature axis, the focus just needs to add a new 
> message/cpim 
> > envelope, and can do this in all 4 cases.
> > 
> > 1. Unsigned
> > BEFORE
> > ...
> > Content-Type: text/plain
> > 
> > Hi
> > -------foo$
> > 
> > AFTER
> > ...
> > Content-Type: message/cpim
> > 
> > From: <sms:+12223334444>
> > 
> > Content-Type: text/plain
> > 
> > Hi
> > -------foo$
> > 
> > 2. Signed by Participant
> > BEFORE
> > ...
> > Content-Type: multipart/signed;boudary=bar
> > 
> > --bar
> > Content-Type: text/plain
> > 
> > Hi
> > --bar
> > Content-Type: application/pkcs7-mime
> > 
> > <signature>
> > --bar
> > -------foo$
> > 
> > AFTER
> > ...
> > Content-Type: message/cpim
> > 
> > From: Alice <sip:[email-masked]>
> > 
> > Content-Type: multipart/signed;boudary=bar
> > 
> > --bar
> > Content-Type: text/plain
> > 
> > Hi
> > --bar
> > Content-Type: application/pkcs7-mime
> > 
> > <signature>
> > --bar
> > -------foo$
> > 
> > 
> > 3. Signed by Focus
> > BEFORE
> > ...
> > Content-Type: text/plain
> > 
> > Hi
> > -------foo$
> > 
> > AFTER
> > ...
> > Content-Type: multipart/signed;boundary=bar
> > 
> > --bar
> > Content-Type: message/cpim
> > 
> > From: Alice <sips:[email-masked]>
> > 
> > Content-Type: text/plain
> > 
> > Hi
> > --bar
> > Content-Type: application/pkcs7-mime
> > 
> > <signature>
> > --bar
> > -------foo$
> > 
> > 4. Signed by Both
> > BEFORE
> > ...
> > Content-Type: multipart/signed;boudary=bar
> > 
> > --bar
> > Content-Type: text/plain
> > 
> > Hi
> > --bar
> > Content-Type: application/pkcs7-mime
> > 
> > <signature>
> > --bar
> > -------foo$
> > 
> > 
> > AFTER
> > ...
> > Content-Type: multipart/signed;boundary=focus-bound
> > 
> > --focus-bound
> > Content-Type: message/cpim
> > 
> > From: Alice <jid:[email-masked]/atlanta>
> > 
> > Content-Type: multipart/signed;boundary=godzilla
> > 
> > --godzilla
> > Content-Type: text/plain
> > 
> > Hi
> > --godzilla
> > Content-Type: application/pkcs7-mime
> > 
> > <signature of participant>
> > --godzilla
> > --focus-bound
> > Content-Type: application/pkcs7-mime
> > 
> > <signature of focus>
> > --focus-bound
> > -------foo$
> > 
> > None of the signature combos requires the whole message. 
> You insert some 
> > stuff at the top, and and the end.  you need to keep a running hash 
> > going in the middle to generate or verify the signature at 
> the end, but 
> > you don't need the whole message to start writing.
> > 
> > For the encryption axis, obviously all the signature examples were 
> > unencrypted and work fine.  If a message is encrypted for a 
> group, the 
> > focus just treats this like any other type of body and slaps a 
> > message/cpim envelope around it to assert who it thinks the From is 
> > (**).  The only time the focus needs to grab the whole 
> message, is when 
> > it is encrypted for the focus and nobody else has the key.  
> Obviously 
> > here, you need the whole message anyway, so CPIM is hardly 
> the limiting 
> > factor.
> > 
> > (**) example:
> > 
> > B. Encrypted with group key
> > BEFORE
> > ...
> > Content-Type: application/pkcs7mime
> > 
> > ***********ciphertext*********
> > -------foo$
> > 
> > AFTER
> > ...
> > Content-Type: message/cpim
> > 
> > From: Alice <sips:[email-masked]>
> > 
> > Content-Type: application/pkcs7mime
> > 
> > ***********ciphertext*********
> > -------foo$
> > 
> > thanks.
> > -rohan
> > 
> > 
> > 
> > 
> > 
> > On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote:
> > 
> >>
> >>
> >> Ben Campbell wrote:
> >>
> >>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote:
> >>>
> >>>> comments inline.
> >>>>
> >>>>     Paul
> >>>>
> >>>> Ben Campbell wrote:
> >>>>
> >>>>> Hi,
> >>>>> In last week's SIMPLE meeting, Orit brought up an issue 
> about how 
> >>>>> we planned to identify contributors when MSRP is used with a 
> >>>>> conference focus. Previously, we had discussed using 
> message/cpim 
> >>>>> wrappers for this purpose.
> >>>>> After thinking through the use case, I think Orit may 
> be correct 
> >>>>> that cpim is unwieldy for this purpose.
> >>>>> The use case I think we have in mind is, you have a 
> text conference 
> >>>>> where each participant has an independent MSRP session with the 
> >>>>> conference focus. The focus acts as a reflector, forwarding 
> >>>>> messages that come in on one participant session to each of the 
> >>>>> other participants. It needs a way to tell the 
> receiving parties 
> >>>>> which participant sent the message. _How_ it determines what 
> >>>>> contributor ID to attach to a given message is out of scope for 
> >>>>> MSRP--that problem belongs to XCON.
> >>>>> We had previously assumed the focus would simply wrap 
> the inbound 
> >>>>> message in a message/cpim document, and use the CPIM 
> "from" field 
> >>>>> for this purpose. This, however, is problematic for chunked 
> >>>>> messages, as the focus would need to buffer the message 
> until it 
> >>>>> had received all the chunks, wrap the completed message 
> in the cpim 
> >>>>> document, and then send that message out to the other 
> participants, 
> >>>>> possibly re-chunking in the process. This does seem to me to be 
> >>>>> burdensome on the focus; it would be nicer if the focus could 
> >>>>> simply forward the individual chunks, and let the 
> endpoints deal 
> >>>>> with re-assembling them.
> >>>>
> >>>>
> >>>>
> >>>> I haven't thought this thru carefully, but I think it should be 
> >>>> possible to wrap the message in a CPIM wrapper without 
> reassembling 
> >>>> it first. It is just a matter of inserting some bytes for the 
> >>>> wrapper in the first chunk. If that pushes the first 
> chunk over 2k 
> >>>> then it might have to be sent as two chunks, then so be 
> it. If the 
> >>>> actual length of the message was provided, then it would 
> need to be 
> >>>> changed. And then each other chunk of the message would 
> need to have 
> >>>> its byte range adjusted. Then, when the last chunk is found, it 
> >>>> needs to have a suffix appended to it to wrap out the 
> CPIM wrapper. 
> >>>> (Actually I don't recall the details of CPIM to know if that is 
> >>>> needed.)
> >>>>
> >>>> So, it takes a bit of work, but not a huge amount.
> >>>>
> >>> I agree this is true, assuming the use of cpim is always 
> that simple. 
> >>> Do we run into any problem if the chunk contained signed 
> or encrypted 
> >>> data? Will the focus ever need to sign or encrypt the data itself?
> >>
> >>
> >> Well, what are the cases?
> >> - the message arriving at the mixer could be signed, 
> encrypted, both,
> >>   neither - by the sender.
> >> - the outgoing message from the mixer could any 
> signing/encryping of
> >>   the incoming message alone, or could remove one or the other.
> >> - the outgoing message from the mixer could be signed, 
> encrypted, both
> >>   or neither - by the mixer.
> >>
> >> I'm not sure how many of those combinations are meaningful 
> - not very 
> >> many I think.
> >>
> >> If the message is encrypted, and the mixer needs to remove that 
> >> encryption, then it cannot escape buffering the whole message.
> >>
> >> If the message is not encrypted, but it is signed with 
> >> multipart/signed, then it should be possible to remove the 
> signature 
> >> on the fly.
> >>
> >> If the message is to be signed and/or encrypted by the mixer, then 
> >> given a suitable algorith, I think it is possible to do it 
> on the fly, 
> >> with the restriction that any out-of-order chunks will need to be 
> >> buffered until their turn arrives. All the stuff that 
> wraps the actual 
> >> encrypted text can still be inserted at the beginning or end.
> >>
> >> I'm not sure of this - would need to study the encoding 
> more carefully 
> >> to be sure, but I think this should work.
> >>
> >> Note that all of this is independent of whether a CPIM wrapper is 
> >> being added or not.
> >>
> >>>> I think the two approaches aren't different enough in the work 
> >>>> required that they should be judged based on that.
> >>>>
> >>>> Its probably more important to get the semantics right. 
> Suppose we 
> >>>> were to go with this new header. And then suppose we had 
> conference 
> >>>> participants sending CPIM wrapped messages that contain a From 
> >>>> header. What identity should the recipient display?
> >>>
> >>> It seems to me that this is a matter for the conference policy to 
> >>> solve, and is not significantly different than if you 
> have a voice 
> >>> conference, and a caller has a different identity in the 
> credentials 
> >>> for a SIP dialog than in the conference policy.
> >>
> >>
> >> Certainly it *can*. But as long as the endpoint can 
> receive identity 
> >> information in two ways there will always be more 
> confusion that if 
> >> there is only one way.
> >>
> >>     Paul
> >>
> > 
> > 
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Aug 2004 11:33:42 -0400

[email-masked] wrote:
> There is a requirement that a chunk should not contain a body greater
 > than 12000 bytes in size unless it is interruptible. If a mixer is
 > adding extra CPIM headers to those chunks making them greater than
 > 1200 bytes, then the mixer needs to re-chunk.

Yes, I agree. But this is a local phenomenon - it can be applied to each 
incoming chunk independently.

So, the first chunk of the message will be enlarged due to the insertion 
of a CPIM wrapper. If that pushes it over 2k, then it needs to be split 
into two chunks. (Or if the mixer's message sending is interuptable it 
can try to send the enlarged chunk and only split it if forced to.)

Any middle chunks are unchanged.

The last chunk also has a few bytes added to complete the CPIM wrapper. 
Again if that pushes it over the 2k limit it may need to be fragmented.

For a server that wants to optimize, the resulting chunks could then be 
placed into an outgoing queue, and potentially merged and refragmented 
into optimal sized chunks.

	Paul