Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-capability-negotiation-05

From: EKR <[email-masked]>
Date: Sat, 10 Mar 2007 19:55:13 -0800

$Id: draft-ietf-mmusic-sdp-capability-negotitation-05-rev.txt,v 1.1 2007/03/11 04:06:19 ekr Exp $

This looks pretty complete.

I've got some minor comments.

S 3.1.
       o  A new attribute ("a=pcfg") that lists the potential 
          configurations supported. This is done by reference to the 
          capabilities from the SDP in question. Multiple potential 
          configurations have an explicitly indicated ordering 
          associated with them. Extension capabilities can be defined 
          and referenced in the potential configurations.  

       o  A new attribute ("a=acfg") to be used in an answer SDP. The 
          attribute identifies a potential configuration from an offer 
          SDP which were used as an actual configuration to form the 
          answer SDP. Extension capabilities can be included as well. 

pcfg goes in the offer and acfg in the answer, right? Can you say
that a little more explicitly.

S 3.8/3.9.1.
   The SDP capability negotiation framework does not define such an 
   alternative, however extensions may do so. For example, one technique 
   proposed for best-effort SRTP in [BESRTP] is to provide different RTP 
   payload type mappings for different transport protocols used, outside 
   of the actual configuration, while still allowing them to be used by 
   the answerer (exchange of keying material is still needed). The basic 
   SDP capability negotiation framework defined here does not include 
   the ability to do so, however extensions that enable that may be 
   defined.  

   ...

   The rtpmap parameter binds an RTP payload type to a media format 
   (codec). While it is possible to provide rtpmaps for payload types 
   not found in the corresponding "m=" line, such rtpmaps provide no 
   value in normal offer/answer exchanges, since only the payload types 
   found in the "m=" line is part of the offer (or answer). This applies 
   to the core SDP capability negotiation framework as well: Only the 
   media formats (e.g. RTP payload types) provided in the "m=" line are 
   actually offered; inclusion of rtpmap attributes with other RTP 
   payload types in a potential configuration does not change this fact 
   and hence they do not provide any useful information. They may still 
   be useful as pure capabilities though (outside a potential 
   configuration).  

Should we offer some guidance about the payload type mappings being
as consistent as possible between the various potential configurations?

S 4.3.

   Finally, if Bob had chosen to use session-level MIKEY instead of SDP 
   security descriptions instead, the following answer would have been 
   generated: 

   ...

In the other examples, there has been an UPDATE to help out middleboxes.
This would have bad side effects with MIKEY, right, since you can't
guarantee that you won't (and in fact you probably will) have to
do a new DH computation and then rekey...

-Ekr

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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Mar 2007 18:28:22 -0400

Thanks for the review and comments Ekr - responses below....

> that a little more explicitly.
Will do. Also note that pcfg can go in an answer as well (as in we have 
not precluded that, but if I recall correctly, also did not say anything 
about that).

> as consistent as possible between the various potential configurations?
Probably a good idea, at least as long as the potential configurations 
don't otherwise require receipt of the answer before you can process 
media based on them.

> do a new DH computation and then rekey...
The idea would be to include exaxtly the same keying material as in the 
previous offer/answer exchange. We've touched on that in the security 
preconditions draft (draft-ietf-mmusic-securityprecondition-03.txt) 
where the assumption is that such cases will not be interpreted as a 
replay attack. From security preconditions:

<quote>
Of course, this duplication of key exchange during precondition 
establishment is not to be interpreted as a replay attack. This issue 
may be solved if, e.g., the SDP implementation recognizes that the key 
management protocol data is identical in the second offer/answer 
exchange and avoids forwarding the information to the security layer for 
further processing.
</quote>

Should we add similar text to this draft ?

-- Flemming