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

[Flemming Andreasen <[e-mail]>]

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



EKR wrote:
> $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.
>
>   
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).


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

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


> -Ekr
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>   

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