Subject: Re: [MMUSIC] Re: Commetns on draft-ietf-mmusic-sdescriptions-02.txt

From: Mark Baugher <[email-masked]>
Date: Tue, 13 Jan 2004 15:05:00 -0800

Magnus, All
    I wanted to refine my point about removing multicast from SDP security 
descriptions to be much more specific:  We want to address only pairwise 
connections in sdescriptions.  So this excludes from consideration multiple 
unicast endpoints in a multimedia session.  We have discussed this with 
several people, and Colin suggested that we take this change to the mmusic 
list.  The rationale for excluding multicast applies to everything that is 
not strictly pairwise:  There is a lot group-security and 
SRTP-synchronization complexity that needs to be considered in a separate, 
non-trivial effort.

   We want to make this change because of a need to apply this 
specification to pairwise connections first and foremost.  The only 
non-multicast feature that we know is affected by restricting our focus to 
pairwise connections is SIP forking, particularly with early media.  The 
implication here is that we will not support this application with the 
pairwise SDP security descriptions spec.

   The pairwise sdescriptions should be consistent with future extensions 
to groups of endpoints  - one of our added goals if we make this change.

best regards, Mark
At 05:57 PM 12/13/2003, Mark Baugher wrote:
>Magnus,
>   My co-authors and I will address your issues prior to the next version 
> of the I-D, which we should submit within the next several weeks.
>
>   I have one comment, however, and that concerns your comments on 
> multicast.  We proposed to the last Wg meeting to drop multicast from the 
> draft altogether and focus just on the unicast - as a divide and conquer 
> strategy.  I expect multicast functionality to be added in a subsequent 
> draft when people are actively designing systems to support it.
>
>   This proposal was posted in the WG minutes to this list and I have 
> heard no dissent from anyone.
>
>cheers, Mark
>At 04:43 AM 12/12/2003, Magnus Westerlund wrote:
>>Hi,
>>
>>I have know read the draft and has thought about most of the open issues 
>>that the draft presents and the discussion during the IETF meeting. There 
>>are a couple of points below that, especially 5, that I believe requires 
>>further discussion and study.
>>
>>
>>1. As a general thing I think authors should think about how the pages 
>>get clipped by the pages. For improved readability one should move any 
>>new sections, etc. that only gets a few line to the next page. One such 
>>example is to start the table of contents on the first page, instead of 
>>on the second. Another if the section 4 heading that are sole on the last 
>>line of a page.
>>
>>2. The table contents may be a bit to detailed, I would think that it 
>>would be acceptable to remove all third level items.
>>
>>3. The introduction contains a normative MUST. I don't think this is 
>>really appropriate. Please find another place to locate this normative 
>>text after the introduction.
>>
>>4. In the last paragraph of section 2, I think this section would benefit 
>>of being split into two paragraphs.
>>
>>5. I think that one must look over the multicast cases and divide them 
>>into different use cases. I think that removing all the multicast is a 
>>bad choice as there are situation where it seems to work. I would start 
>>by dividing the usage into scenarios where one can use the a=crypto 
>>successfully.
>>
>>- The one to many, using ASM case. This is a advertisement case. Only the 
>>intended sender declares his SSRC/ROC/SEQ to ensure that all receivers 
>>does not use the senders SSRC and causes a two time pad with it. As all 
>>receivers are unsynchronized unless other mechanism is used, there might 
>>happen SSRC collisions. However if you either don't encrypt the RTCP, 
>>which is the only thing they will send, it is not a problem. Also if RTCP 
>>encryption is used, it might be deemed acceptable with the low risk of 
>>two time pads that exist. However this is clearly a security trade off.
>>
>>- The one to many, using SSM, as the receivers can't send to anybody else 
>>there is no problem. If one uses unicast RTCP feedback, the same security 
>>consideration regarding RTCP two time pads apply, however the 
>>distribution of the offending packets will not be the same as for ASM use 
>>cases.
>>
>>- The multicast conference case, with a central session control instance. 
>>As all participants speak only with the central control entity it can 
>>ensure that SSRC, collision is avoided if the same key are used. However 
>>in this case it is probably better to use individual master keys for each 
>>sender. However there seems to be some need to fix the a=crypto syntax to 
>>support this case.
>>
>>- The multicast conference, each sender announces there attributes 
>>individually to each participant. In this case all should be required to 
>>use individual master keys. Thus there is no risk for two time pads.
>>
>>As I see it with a few changes to the a=crypto attribute multicast can be 
>>fixed. However there is need to flesh out the scenarios and ensure that 
>>the signalling works for these.
>>
>>So as a conclusion there is need for more work in the multicast 
>>environment. Also statement as the second bullet in 4.1.1.2 is not correct.
>>
>>6. void
>>
>>7. Section 5.1.1.1 the example line includes a extra "<" at the 
>>"lifetime" parameter.
>>
>>8. Section 5.1.1.1: How does one know what type of key that is specified 
>>in the key field. To my understanding there are a possibility for at 
>>least three different levels of keys in SRTP. A top level master key, a 
>>master key for a single SSRC, individual keys for streams. There is 
>>currently no way of differentiating or requiring a key to be of a certain type.
>>
>>9. In section 5.1.1.1 there is a rule that the key length must be correct 
>>for the signalled length. However a BASE64 encoded key|salt combination 
>>may need some padding. So I assume that key lengths changing it to up to 
>>the next base64 boundary is okay.
>>
>>10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about 
>>how the number of packets are calculated and applies to. Is this the 
>>total number of packets a master key can be used for, or does it applies 
>>to any derived key, and when one of the derived keys reach this number it 
>>needs to rekey? I don't think the text in section 5.3.1 really helps 
>>either, as it makes it impossible for individual participants to actually 
>>calculate how many packets that has been used by the master key.
>>
>>11. Section 5.2, I think this section could gain by an table that 
>>tabulates the crypto suits and its major parameters for easy access 
>>instead of the description.
>>
>>12. Section 5.3.1: The SRC parameter I think need to be better 
>>clarified.  If one gives a ROC/SEQ is given, it MUST be given in relation 
>>to the SSRC for which it is valid.
>>
>>13. When it comes to offer answer for multicast, it must be made clear 
>>how one uses SRC to ensure that a joining participant selects a SSRC that 
>>will not collide.
>>
>>14. Section 5.3.1, what is an invalid SSRC? How do you know.
>>
>>15. How is the the usage of late binding and shared master key indicated, 
>>to allow a receiver to determine what is used.
>>
>>16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key 
>>derivation should be performed every packet. I would recommend to remove 
>>this wrong motivation, and simply state it as being an exception.
>>
>>17. In 6.1.1.2 you have a restriction that from-to must only be used in 
>>"recvonly", doesn't this depend on the scoping of these attributes. As 
>>pointed out in point 10, the from to context is not clear.
>>
>>18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one?
>>
>>19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with 
>>SSRC when common master key is used.
>>
>>20. In 6.1.2.1, Before the open issue, there is a statement that the is 
>>no need for optional parameters. I think this is not, true or what is 
>>meant with optional parameters must be clarified, there are certain use 
>>case that definitely will require use of certain parameters.
>>
>>21. In 6.1.3.2 , there is text saying that session parameters shall be 
>>ignored, I don't agree with that.
>>
>>22. In 6.1.3, In the paragraph after the bullets, one may get the 
>>impression that multiple sources only are needed in multicast. That is 
>>not true. Also in unicast a single end-point may need to use multiple 
>>SSRCs, for example for retransmission.
>>
>>23. In 7.3, I think the RECOMMEND to use a key management protocol if not 
>>carried in authenticated and encrypted transport format, should be a SHOULD.
>>
>>24, Section 7.3, Question, How does one know that the signalling over 
>>network (b) even is encrypted.
>>
>>25. Section 8: "key-params" does not need to be recursively defined, the 
>>second "key-params", needs only to be a "key-param"
>>
>>26. Section 8.1: key-method-ext, isn't this a "token"? I think 
>>restricting the usage of other special characters then "_" is possibly to 
>>restricted.
>>
>>27. Section 8.2, is really decimal form for SSRC the best form. I would 
>>recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 
>>bit binary identifier, not a number in its normal sense.
>>
>>28. Section 10.2.1, I think that you should review the standard IANA 
>>registration levels in RFC 2434, I think that for the key method, it is 
>>probably, "standards action" that is the right one.
>>
>>29. Section 10.2.2: I don't think that SRTP crypto suit registrations 
>>needs only to take "inline" into consideration. I think it should say 
>>that it should be defined in relation to applicable key-methods. I also 
>>think that the IANA section should be a bit more explicit what really is 
>>required.
>>
>>
>>Cheers
>>
>>Magnus Westerlund
>>
>>Multimedia Technologies, Ericsson Research EAB/TVA/A
>>----------------------------------------------------------------------
>>Ericsson AB                | Phone +46 8 4048287
>>Torshamsgatan 23           | Fax   +46 8 7575550
>>S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic

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