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

From: Mark Baugher <[email-masked]>
Date: Mon, 18 Aug 2003 15:31:16 -0700

Magnus, Dan
   Thanks to Magnus for the careful review.  Pardon my late response but we 
are now about ready to revise the I-D and can benefit from an exchange on 
these issues.   I have a few comments below.

At 04:21 PM 7/30/2003 -0700, Dan Wing wrote:
> > Here is my comments on this draft.
>
>Thanks for your comments.  Sorry for the delay, I have been out of
>the office.
>
> > 1. As a WG draft you should have the short copyright statement and not
> > 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
> > security terminology.
>
>Okay.
>
> > 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.
>
>-sdescriptions- is only trying to describe a=crypto for the RTP/SAVP
>(SRTP) transport.

Yes and this is a shift from draft 0.  Here is our thought process:  We 
will not be implementing sdescriptions for anything but the RTP/SAVP (we 
never planned to specify security descriptions for media, which is 
something that I'd expect to see in the fmtp).  I think we'd be making a 
mistake to specify something that we don't plan to implement and the result 
will likely have a lot of errors, which will likely only be discovered when 
someone tries to implement it.  This is what I think happened with k=.  If 
k= was implemented, it was too narrow and the result is that it needs to be 
replaced.

That being said, I believe this framework is general enough to be used by 
other SDP transports.  But we really are only providing the definitions for 
RTP/SAVP.

> > 4. Section 3.4, I think the session parameters are actually specific to
> > 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?

Yes, session parameters are distinct from key parameters.  The crypto-suite 
are specific to the key parameters and independent from the session parameters.

> > Secondarily it can be dependent on more things.
>
>Could you explain?
>
> > 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.
>
>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).

I think we'll be more future-proof if we just face the fact that encryption 
and authentication transforms can often be specialized to the 
transport.  That is what happened to counter mode in IPsec versus 
SRTP.  TBS, I don't see any reason why a specification for a specific 
transport other than RTP/SAVP cannot reference an RTP/SAVP 
crypto-suite.  This will give us the benefit of reuse without trying to 
force a single definition on all transports.

> > 6. Section 4.1, Is usage of multiple a=crypto lines allowed. IF yes this
> > section contradict this.
>
>I agree some different wording would clarify this section.  Will work
>on it.
>
> > 7. Section 4.1.4, last sentence: How can one add a new name that is
> > identical and still carry any difference. Please reword.
>
>Okay.
>
> > 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.
>
>We're strongly considering dropping the URI parameter.  If anyone
>feels strongly about keeping it, speak up.

We are discussing this.  I imagine that the URI will take a person to a web 
page for the purposes of authorization.  After that, the key can be 
obtained by application-specific means, e.g. it could be sent in email.  Or 
as Magnus has pointed out, the format can be crypto-suite dependent and the 
format of the key can be as described in the sdescriptions 
draft.  Personally, I don't think we need to define this further but leave 
it to an application.  It's more flexible that way.

> > 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.
>
>We'll tighten up that wording, thanks.

I don't think any one of the three are always sufficient.  The fact that we 
need to intrude into RTP processing in this way is a drawback to SRTP.  The 
SSRC is needed to identify the crypto context prior to the start of the RTP 
session.  In a pair-wise session, or if there is only a single sender, the 
SSRC might not be needed.  In general, it will be.  The ROC and SEQ are 
needed to generate the SRTP keystream for AES-CM and f8.  If the receiver 
does not join the session after session commencement, the ROC and SEQ might 
not be needed.  But because the SEQ starts at a random value in RTP, we 
need to account for boundary cases where the SEQ starts very close to its 
maximum value.  All of this is very messy.  But in a pairwise session of 
short duration, where the SEQ starts at zero, the SEQ and ROC do not need 
to be signaled.

> > 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.
>
>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.)
>
> > 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.
>
>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.
>
> >   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.
>
>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-?

I'd prefer that we just point to the SRTP specification.

> > 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.
>
>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?
>
> > 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.
>
>Okay, we'll examine that.  Thanks.
>
> > 14. Section 6.2, second paragraph, first sentence: The attribute is
> > crypto not SRTP as it says in the text.
>
>Okay.
>
> > 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.
>
>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.
> > Please simplify this.
>
>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.
>
> > 17. Section 7, The absolute URI should not rely only on RFC 2396, there
> > 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.

yes, thanks.

Mark

>-d
>
> > 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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Aug 2003 13:39:31 +0200

Hi Dan,

My clarifications and further comments below:

> -sdescriptions- is only trying to describe a=crypto for the RTP/SAVP

Okay, the question is if this is acceptable. As I can see it there are 
two ways when defining "a=crypto"

1. As a future safe replacement of a=k with possibility to declare new 
ways of transporting the keys by using a place holder. That way one 
could in the future define a=crypto to be valid also for other profiles 
and media types.

2. Only define a=crypto for SRTP. However there are still need to for 
the possibility to extend it for future crypto suites for SRTP.

Personally I don't have any strong view on the alternatives. However I 
feel there is need for some discussion on what the correct way forward is.

There also seem to exist possibilities that some of the k= usage should 
actually be defined using a=crypto to take care of all concerns 
regarding what encryption method is used etc.

>>Secondarily it can be dependent on more things.

I think you helped explain the problem here. First, the session 
parameters that can be used are always in relation to the crypto suit. 
This means that each crypto suit needs to define which parameters that 
are valid for the crypto suit. Secondly there are certain parameters 
that will be present in all SRTP suites so far defined.

Taking the "encrypted_srtcp" as an example. Can't a future crypto suit 
define that RTCP will always be encrypted and the need for the parameter 
is removed. This may not be a good way of defining it, however it is 
possible.

So the point I try to make is that each crypto suit should define what 
parameters it supports.

> trying to only define usage with SRTP (RTP/SAVP).

Depending on what is the agreed on path, this comment either goes away 
or needs to be addressed.

> an Offer contains multiple media lines with the same port.)

I don't see a problem with defining it this way. However there is need 
to clearly define that this specification does not cover the case with 
multiple m= line for the same port.

> Do you feel putting like the above paragraph might be useful in

Yes, and explanation on how the parameters a=crypto are used for this 
purpose.

> Is that your intent of having the SRTP-WINDOW-SIZE indicated in the

As SRTP-WINDOW-SIZE is application dependent there might be need for an 
application to hint how big this window should be to work satisfactory. 
However there might be enough information given in SDP attributes like 
a=maxprate and the bandwidth modifiers to allow a receiving side to 
derive the parameters. One could allow the parameter as a hint to the 
application.

Best Regards

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Tue, 19 Aug 2003 09:08:19 -0700

Magnus,

At 01:39 PM 8/19/2003 +0200, Magnus Westerlund wrote:
>Okay, the question is if this is acceptable. As I can see it there are two 
>ways when defining "a=crypto"
>
>1. As a future safe replacement of a=k

Do you mean k=?

>with possibility to declare new ways of transporting the keys by using a 
>place holder. That way one could in the future define a=crypto to be valid 
>also for other profiles and media types.
>
>2. Only define a=crypto for SRTP. However there are still need to for the 
>possibility to extend it for future crypto suites for SRTP.
>
>actually be defined using a=crypto to take care of all concerns regarding 
>what encryption method is used etc.

I think that a=crypto does everything that k= does.  My concern is that 
there might be an unforeseen need for extension for a particular transport.

>I think you helped explain the problem here. First, the session parameters 
>that can be used are always in relation to the crypto suit.

No, this is not the case:  They are specific to the transport.  The 
crypto-suite may or may not be specific to the transport (see below).

>This means that each crypto suit needs to define which parameters that are 
>valid for the crypto suit. Secondly there are certain parameters that will 
>be present in all SRTP suites so far defined.
>
>is removed. This may not be a good way of defining it, however it is possible.

I suppose it is but it would be a very brittle way to define the crypto 
suite, which *may be* orthogonal to the transport.  In the first submission 
of this work, we expected the crypto suite to be transport 
independent.  The reason it is not is because we have seen examples of the 
crypto suite being tailored and optimized for a particular transport.  For 
example, AES counter mode for SRTP re-uses the RTP sequence number to 
obviate the need to add a nonce to the header and save precious bits on low 
bandwidth links.  IPsec decided to put a nonce into the IPsec transport 
header for AES counter mode - the IV field - rather than overload the 
sequence number.  For sdescriptions, it seemed to us to be safer to not try 
and develop a single set of crypto suites for all transports since the 
namespace could become unwieldy (e.g. AES-CTR-128-HMAC-SHA1-80-SRTP, 
AES-CTR-128-HMAC-SHA1-80-IPSEC).

You seem to be taking this to its logical conclusion of putting all 
transport-specific parameters into the crypto suite, but I don't think we 
want to do that.  For one thing, it will result in too many crypto 
suites.  A bigger problem is that some parameter support a range of values, 
such as the size of the MKI.

>So the point I try to make is that each crypto suit should define what 

We made a distinction of parameters that are specific to the key, these are 
the domain of the crypto suite, versus parameters related to the transport, 
these are the session parameters.

>Depending on what is the agreed on path, this comment either goes away or 
>needs to be addressed.

I think we created this confusion by changing course on the WG.  We 
originally wanted a replacement for k= because of its deficiencies, which 
we describe in the I-D.  We developed some misgivings on this course when 
working through the O/A, which is very transport specific.  It did not seem 
prudent to define secure transports, O/A, etc. for fax, whiteboard, modem, 
etc. if we are not planning on testing these specifications on real-world 
implementations.

I guess we are in a bit of a muddle on this important point.  Sorry about 
that.  What we feel confident doing here is defining the best possible 
specification for SRTP.

>I don't see a problem with defining it this way. However there is need to 
>clearly define that this specification does not cover the case with 
>Yes, and explanation on how the parameters a=crypto are used for this purpose.

I think that a non-zero MKI explains it all.

>a=maxprate and the bandwidth modifiers to allow a receiving side to derive 
>the parameters. One could allow the parameter as a hint to the application.

ok.  I think the outstanding problem that we need to resolve with the WG is 
to what degree we generalize a=crypto beyond the SRTP transport.

thanks, Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Aug 2003 19:05:30 +0200

Hi Mark

More comments below.

>> 1. As a future safe replacement of a=k

Yes.

> there might be an unforeseen need for extension for a particular transport.

Not as currently specified. Can't k= be used to specify the use of DES 
on complete RTP and RTCP packets? This is certainly something different 
than what so far is defined. However I don't know if there is any need 
for including this.

> suite, which *may be* orthogonal to the transport.  In the first 
> submission of this work, we expected the crypto suite to be transport 
> independent.  The reason it is not is because we have seen examples of 
> the crypto suite being tailored and optimized for a particular 
> transport.  For example, AES counter mode for SRTP re-uses the RTP 
> sequence number to obviate the need to add a nonce to the header and 
> save precious bits on low bandwidth links.  IPsec decided to put a nonce 
> into the IPsec transport header for AES counter mode - the IV field - 
> rather than overload the sequence number.  For sdescriptions, it seemed 
> to us to be safer to not try and develop a single set of crypto suites 
> for all transports since the namespace could become unwieldy (e.g. 
> AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC).
> 
> transport-specific parameters into the crypto suite, but I don't think 
> we want to do that.  For one thing, it will result in too many crypto 
> suites.  A bigger problem is that some parameter support a range of 
> values, such as the size of the MKI.

What do you mean with transport here? Depending on what level you mean I 
think that one must in fact make the crypto suits transport dependent.

If you with transport means for example RTP and the used profile the 
crypto suit must in fact be transport dependent as I think your example 
crypto suits AES-CTR-128-HMAC-SHA1-80-SRTP, 
AES-CTR-128-HMAC-SHA1-80-IPSEC visualize. Even if the same crypto 
algorithm is used by both SRTP and IPSEC the other parameters are not 
identical I would assume, or are they? There is need to know that IPSEC 
should be applied and that SRTP is not needed. Therefore I would assume 
that the crypto suits must be in fact be dependent on encryption method 
which might imply certain transports.

What we are still discussing in fact are if the a=crypto attribute only 
should be applicable for SRTP independent on lower layers that transport 
them, or we should make it possible for future extensions that might 
apply for usage with other crypto methods?

> We made a distinction of parameters that are specific to the key, these 
> are the domain of the crypto suite, versus parameters related to the 
> transport, these are the session parameters.
> 
> 

In fact I would instead say that sessions parameters are SRTP parameters 
that are not depending on the crypto suit. Are you certain that 
SEQ/ROC/SSRC is session parameters. I think they would be in fact 
useless if one develops a crypto suit that are based on explicit IVs 
instead of the current implicit ones.

As a result of that all session parameters are in direct relation to 
SRTP usage I don't see a problem with tying them to the crypto suit as 
these crypto suits are directly related SRTP and no other protocol. None 
of the listed parameters in section 4.3 would care if the RTP is 
transported over IP/UDP, IP/DCCP, or something completely different as 
long as the packet borders are recoverable.

> originally wanted a replacement for k= because of its deficiencies, 
> which we describe in the I-D.  We developed some misgivings on this 
> course when working through the O/A, which is very transport specific.  
> It did not seem prudent to define secure transports, O/A, etc. for fax, 
> whiteboard, modem, etc. if we are not planning on testing these 
> specifications on real-world implementations.
> 
> I guess we are in a bit of a muddle on this important point.  Sorry 
> about that.  What we feel confident doing here is defining the best 
> possible specification for SRTP.

I agree about this. I hope that this message exchange has made it clear 
to the general public that you would like to change the intention. As 
this being a WG document you are in fact required or at least strongly 
encourage to ask the group for input on such changes.

I don't think you need to consider all strange, non used methods. 
However what I think the WG needs to consider is if it should be 
possible to extend "a=crypto" to carry keys for, DES and 3DES of the 
complete RTP packet as defined in the RTP spec, or something else that 
people see need of?

If the result of that question is a yes, then I think that the a=crypto 
attribute must either put in a method indicator first or make the crypto 
suite carry implicit information about the method and the structure of 
the rest of the a=crypto line.

> I think that a non-zero MKI explains it all.

What about the usage of <From, To>? I couldn't found anything about it. 
What I think is important is to resolve how a rekeying with this 
mechanism will happen.

I don't think that the following section actually explains how to 
perform the rekeying to a point of interoperability.

Section 5.7:
   "When an active SRTP session is rekeyed, this is indicated by sending
    a new SDP.  Rekeying is done following the rules described for a
    normal Offer/Answer exchange.  The Answerer can take this
    opportunity to rekey the traffic it is sending, if the Answerer
    desires.  During rekeying, the session parameters cannot be changed
    and MUST NOT be specified in the Offer or the Answer. "

I think that you must in fact clarify that the key for rekeying must be 
connected to a MKI or "from,to" interval to indicate when valid.

> ok.  I think the outstanding problem that we need to resolve with the WG 
> is to what degree we generalize a=crypto beyond the SRTP transport.
> 

Agreed, I hope that some other people can give there opinion about this.

Best Regards

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Thu, 21 Aug 2003 15:24:43 -0700

hi Magnus,
At 07:05 PM 8/20/2003 +0200, Magnus Westerlund wrote:
<...>
>Not as currently specified. Can't k= be used to specify the use of DES on 
>complete RTP and RTCP packets? This is certainly something different than 
>what so far is defined. However I don't know if there is any need for 
>including this.

I didn't precisely say what I intended:  One can *extend* sdescriptions to 
do anything that k= does.  Adding DES or 3DES, for example, is done by 
adding a new crypto-suite.

>>sequence number to obviate the need to add a nonce to the header and save 
>>precious bits on low bandwidth links.  IPsec decided to put a nonce into 
>>the IPsec transport header for AES counter mode - the IV field - rather 
>>than overload the sequence number.  For sdescriptions, it seemed to us to 
>>be safer to not try and develop a single set of crypto suites for all 
>>transports since the namespace could become unwieldy (e.g. 

Sorry, I meant transport (e.g. RTP/SAVP) in the SDP sense,
m=<media> <port> <transport> <fmt list>.
There is really no reason why AES-CM-128-HMAC-SHA1 could not serve multiple 
transports, in principle, because it uses AES counter mode and HMAC-SHA1, 
both are standard definitions.  But they can diverge:  SRTP permits a 
128-bit input key for deriving HMAC-SHA1 whereas IPsec requires a 160-bit 
input, IPsec uses a longer counter, etc.  There is no reason why future 
crypto suites, however, can't have identical definitions.  I think that 
this is preferable.

But we can't have identical definitions for the session parameters because 
we're talking about different SDP transport protocols, e.g. unlike SRTP, 
IPsec has no notion of a variable-length key index (probably owing to the 
differences between a kernel and application implementation), and of course 
no notion of SRTCP which can be encrypted or not encrypted.

>crypto suits AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC 
>visualize. Even if the same crypto algorithm is used by both SRTP and 
>IPSEC the other parameters are not identical I would assume, or are they? 
>There is need to know that IPSEC should be applied and that SRTP is not 
>needed. Therefore I would assume that the crypto suits must be in fact be 
>dependent on encryption method which might imply certain transports.
>
>them, or we should make it possible for future extensions that might apply 
>for usage with other crypto methods?

I want sdescriptions to be extensible to other SDP transports.  It 
definitely has to support extension with other crypto methods.

>>put in a method indicator first or make the crypto suite carry implicit 
>>information about the method and the structure of the rest of the 
>>a=crypto line.
>
>
>What I think is important is to resolve how a rekeying with this mechanism 
>will happen.

This can be done with the current definitions based on the sequence number, 
MKI, and lifetime.

>I don't think that the following section actually explains how to perform 
>the rekeying to a point of interoperability.
>
>Section 5.7:

I think Dan, Flemming and I need to discuss this further.

>Agreed, I hope that some other people can give there opinion about this.

I hope so too.  As it stands now, this I-D is a framework for all 
transports but with definitions only for SRTP.  We feel we can generalize 
O/A for all transports.  But the session parameters are SRTP only as are 
the cryptographic-key parameters.  If this is okay with the WG, then there 
is no problem for us.

Thanks, Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Aug 2003 08:58:23 +0200

Hi Mark,

To try to summarize the last mails in the discussion:

1. You are going to create a framework that may be used in the future 
also for other transports then RTP/SAVP. However you will only define 
crypto suits that apply for RTP/SAVP.

2. There is need to resolve how "a=crypto" is used for doing rekeying in 
a synchronized way.

3. Input from others on these issues (especially the first) are desired.

I have some comments upon the first thing. I think that this intention 
is a good one. In respect to the last version I think there are some 
work on clarifying how this will be done. The big issue that needs to be 
resolved is:
- How to connect a crypto suit to transport? Either you need to define a 
crypto suit for each transport, or in cases where there might be 
multiple transport that can use the crypto suit ensure that the 
transport context will be enough to resolve this.

Cheers

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 22 Aug 2003 09:01:55 -0400

> crypto suits that apply for RTP/SAVP.

We probably need to elaborate on this one a bit:

The original intent with the draft was to define a mechanism that can be
used to describe and negotiate (using offer/answer) SRTP parameters for SRTP
media streams. As always, it is desirable to define a general mechanism to
do this rather than just a specific one, however I do have some concerns
about scope explosion here as we are not trying to define a mechanism that
can be used to negotiate security parameters for any kind of stream, e.g.
establish a TLS session or setup an IPSec SA. If it turns out the mechanism
can be used to do that, then great, however this in itself should not be a
goal. I think a reasonable constraint is that the security parameters must
either be such they than just be advertised (e.g. for SAP) or they can be
negotiated in a single offer/answer exchange. Anything that doesn't fit
within those constraints is out of scope.

As far as the security mechanisms are concerned, we need to make a
distinction between:
1. The "method" being used for security and any parameters associated with
that
2. The crypto-suites being used and any parameters associated with that.

By method, I mean for example SRTP, RFC 3550 Section 9, etc. Not all methods
can be used with all transports, for example RFC 3550 Section 9 cannot be
used for RTP/SAVP, but there could conceivably be more than one method used
for a particular transport. Where negotiation is involved, it would be
desirable to be able to specify different methods, at least for the initial
offer/answer exchange. For subsequent offer/answer exchanges it could be
more complicated as the media stream packets themselves may not necessarily
have an indication of which method is being used and a graceful switchover
thus becomes complicated (unless you use a different port).

The crypto-suites will be interpreted within the context of a method (as you
indicated earlier) and will have certain parameters associated with them.

Going back to offer/answer, we can probably come up with a set of generic
rules that apply to all methods and crypto-suites, however I suspect that
for most, there will be a need to further define method-specific and maybe
even crypto-suite-specific offer/answer rules, with SRTP being one such
case. Thus, the draft will define a framework for advertising and
negotiating security parameters and provides the details for how to do it
for SRTP, but in order to use it for anything other than SRTP, additional
specification would be needed (in a seperate RFC).

How does this sound ?

> 2. There is need to resolve how "a=crypto" is used for doing rekeying in

Agreed.

> - How to connect a crypto suit to transport?

I think crypto-suites should be defined within the context of the method
(which includes transport).

> Either you need to define a

I prefer being explicit and defining it for each method/transport; it also
makes the name space issue a lot cleaner.

-- Flemming