Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Jul 2003 17:06:44 +0200

Hi,

Here is my comments on this draft.

1. As a WG draft you should have the short copyright statement and not 
only the long one at the end of the draft.

2. In section 1 I would like that you clarify that RFC 2828 contains 
security terminology.

3. Section 3.1. This section needs to be improved. As I understand it 
the a=crypto attribute can be used with any transport and media. 
Therefore the section should not start with defining that this defines 
the value for RTP/SAVP. The actual crypto suits will be required to be 
registered and defined for each individual transport. There might in 
fact be even further restrictions that apply to future crypto suits.

4. Section 3.4, I think the session parameters are actually specific to 
the crypto suit, primarily. Secondarily it can be dependent on more things.

5. Section 3 and 4. In general I think the basic definition of the 
a=crypto attribute can be more cleanly separated from the specific 
application for SRTP.

6. Section 4.1, Is usage of multiple a=crypto lines allowed. IF yes this 
section contradict this.

7. Section 4.1.4, last sentence: How can one add a new name that is 
identical and still carry any difference. Please reword.

8. Section 4.2, I think there is a large shortcoming regarding the uri: 
parameter. I think one must clearly define the format one retrieves the 
keys when using the URI. Of course this format can be crypto suit 
dependent.

9. Section 4.3.1, second and third paragraph. I think the definition of 
the SSRC, ROC, SEQ, could be better done. As I understand it any of the 
three is sufficient, why not express it that way. Then one MAY have the 
parameter anyway.

10. Section 5.4, second paragraph: I think the limitation you would like 
to declare here needs some discussion. First you forbid the usage of 
multiple m= lines on the same port, after last weeks discussion I don't 
know if this is acceptable, at least not without further motivation. I 
would also write some recommendations/considerations regarding grouping 
  of media lines here.

11. Section 5.7, I am not certain that session parameters can't be 
restrained from being changed. For example the SRC (ROC) parameter seems 
one that might need to be included and changed in an offer for rekeying. 
  Are there any synchronization problem that can arise when doing 
rekeying? There seems to be need to define from what seq the new key are 
valid.

12. When it comes to SRTPs protection mechanism it seems necessary to be 
able to define the window size using the a=crypto parameter. There are a 
lot of difference between a uncompressed video stream running at a 
couple of hundreds of Mbyte/s using 100 000 packets each second. This 
will require a much larger window then a 64 kbit stream that sends 15 
packets every second.

13. Section 6.1 First paragraph, last sentence. The attack is only 
avoided if there is one master key per SSRC, not media stream. I think 
that there is some ambiguity in the use of media stream, which needs to 
be clarified to avoid misunderstanding.

14. Section 6.2, second paragraph, first sentence: The attribute is 
crypto not SRTP as it says in the text.

15. Section 7.: The ABNF does not define the extension space. For 
example the crypto-suite definition should have an extra alternative 
crypto-suit-extension which is VCHAR. I think the whole ABNF needs to be 
thought through to be more complete in the extension sense.

16. Section 7. Why have the 2^ optional value if it does not matter. 
Please simplify this.

17. Section 7, The absolute URI should not rely only on RFC 2396, there 
is an extension to that document, please see RFC 2732.

18. Last page, has not the normal number of lines.

Best Regards

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Jul 2003 16:21:30 -0700

> Here is my comments on this draft.

Thanks for your comments.  Sorry for the delay, I have been out of
the office.

> only the long one at the end of the draft.

Yes, sorry we didn't correct this, I see you commented on this same
issue when you reviewed -00.

> 2. In section 1 I would like that you clarify that RFC 2828 contains

Okay.

> fact be even further restrictions that apply to future crypto suits.

-sdescriptions- is only trying to describe a=crypto for the RTP/SAVP
(SRTP) transport.

> the crypto suit, primarily.

But "encrypted_srtcp" can be specified for any and all crypto suites.  Are
there session parameters that are specific to a cryptographic suite?

> Secondarily it can be dependent on more things.

Could you explain?

> a=crypto attribute can be more cleanly separated from the specific

You mean, for example, to allow -sdescriptions- to define the keys
used by some non-SRTP application (whiteboarding, perhaps)?  We're
trying to only define usage with SRTP (RTP/SAVP).

> 6. Section 4.1, Is usage of multiple a=crypto lines allowed. IF yes this

I agree some different wording would clarify this section.  Will work
on it.

> identical and still carry any difference. Please reword.

Okay.

> keys when using the URI. Of course this format can be crypto suit

We're strongly considering dropping the URI parameter.  If anyone
feels strongly about keeping it, speak up.

> three is sufficient, why not express it that way. Then one MAY have the

We'll tighten up that wording, thanks.

> would also write some recommendations/considerations regarding grouping

In this I-D, we will be removing all references to multiple media lines
with the same port.  A completely separate, unrelated, Internet Draft
needs to be written -- with consensus from the WG -- describing how multiple
media lines with the same UDP port are supposed to be interpreted.

(As an aside, the behavior for multiple media lines with the same port
hasn't been specified elsewhere, so it is ambiguous.  I personally feel we
need to create an unambigiuos method to express the desired behavior when
an Offer contains multiple media lines with the same port.)

> one that might need to be included and changed in an offer for rekeying.

Good point.  We haven't put enough thought into rekeying yet as it's
unnecessary with voice applications and the maximum key lifetimes of
the crypto suites defined in SRTP.

> rekeying? There seems to be need to define from what seq the new key are

That seems to be more a problem with SRTP than -sdescriiptions-.

To resolve the synchronization problem you have to use a per-packet MKI
(which adds a few bytes to each SRTP packet) or the "from,to" mechanism
(which doesn't add bytes to each SRTP packet); both MKI and "from,to"
are described in SRTP itself.

Do you feel putting like the above paragraph might be useful in
-sdescriptions-?

> will require a much larger window then a 64 kbit stream that sends 15

SRTP (draft-ietf-avt-09.txt) says that the SRTP-WINDOW-SIZE is a
receiver-side, implementation-dependent parameter.  If it is signaled
in a unicast SDP, SRTP-WINDOW-SIZE would become a sender-side parameter.

Is that your intent of having the SRTP-WINDOW-SIZE indicated in the
a=crypto line?

> be clarified to avoid misunderstanding.

Okay, we'll examine that.  Thanks.

> crypto not SRTP as it says in the text.

Okay.

> thought through to be more complete in the extension sense.

Yes, it does.

In Vienna it was also pointed out that we need IANA registration of
all of the stuff in -sdescriptions-, as well.  We'll be adding that
to the next I-D.

> 16. Section 7. Why have the 2^ optional value if it does not matter.

At an earlier review, Mark was asked to have a method to specify
power-of-two key lifetimes.  This seemed the easiest way to allow
specifying power-of-two key lifetimes.

But rereading the draft, I see we never added text explaining the
purpose of "2^"!  We'll add that at the next revision.  Thanks.

> is an extension to that document, please see RFC 2732.

Thanks.

> 18. Last page, has not the normal number of lines.

Again, thanks for your review.

-d