Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
RFC 5124

Notify list changed from jo@netlab.tkk.fi, csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com, dwing@cisco.com to magnus.westerlund@ericsson.com, jf.mule@cablelabs.com, dwing@cisco.com, taylor@nortel.com, csp@csperkins.org

[Ballot comment]
I think Jon's comment is getting at the same issue.
Long term we want people to be able to offer best-effort security--offer both secure and non-secure and select secure if it is available at both ends.
The important thing will be to let the user know whether we have security rather than to fail if we do not.
I think it is fine to ignore this issue for now provided that we plan on updating this spec wehn the appropriate mmusic work concludes.

[Ballot comment]
Following on Magnus' DISCUSS, I also think it's premature to discuss  SDP capability negotiation scenarios in this document. Perhaps it would be better to say that you MUST not offer secure and insecure media simultaneously in the absence of some future protocol mechanism updating this specification. I just wanted to point out that more affected text lives in the second paragraph of 3.3.4, and of course in the paragraph above the one in 3.3.1 cited by Magnus. Furthermore, all of 3.3.1 seems hastily written and should be cleared of various grammar woes ("the answerer the answerer", etc).

Also, at the end of the first paragraph of the Sec Cons:

  The SAVP profile does not add, nor take away,
  any security services compared to SAVP. 

Surely this should be "The SAVPF profile does not add..." etc

[Ballot discuss]
Section 3.1.1:

  "If an offer contains multiple alternative profiles the answerer the
  answerer SHOULD prefer a secure profile (if supported) over non-
  secure ones.  Among the secure or insecure profiles, the answerer
  SHOULD select the first acceptable alternative to respect the
  preference of the offerer. "

I think we have an issue here in relation to describing how one offers alternatives. The above text makes no references to how one accomplish the indication of alternatives. Which I think is the only reasonable solution given that we have no defined way of providing alternatives. SDPcapneg is under development and grouping of media lines (RFC 3388) does lack an attribute with the appropriate semantic.

Due to this there is a serious issue with the Section 3.4, Example 4:

This SDP indicates to the RTSP client that it should setup both media streams, one with SAVPF the other with AVPF.

I would also like to point out that the SDP lacks a=control to indicate control URLs.

Section 5:

"  Note that the rules for sharing master keys apply as described in
  [4] (e.g., Section 9.1). In particular, the same rules for avoiding
  the two-time pad (keystream reuse) apply: a master key MUST NOT be
  shared among different RTP sessions if the SSRCs used are unique
  across all the RTP streams of the RTP sessions that share the same
  master key."

I think there is missing "unless guaranteed" in the above rule sentence. Only if the SSRCs over all the session using the same keys are unique can the same master key be used.

[Ballot comment]
Section 3.3.2:

"        Note: To change any of the profiles in use, the client needs
        tear down the RTSP session (using the TEARDOWN method) and re-
        establish it using SETUP.  This may change as soon as media
        updating (similar to a SIP UPDATE or re-INVITE) becomes
        specified. "

This is not totally correct, as it is possible to teardown an individual media stream without tearing down the whole RTSP session I therefore suggest the following formulation:

        Note: To change any of the profiles in use, the client needs
        tear down that media stream (and possibly the whole RTSP session)
      (using the TEARDOWN method) and re-establish it using SETUP.  This
        may change as soon as media updating (similar to a SIP UPDATE or
        re-INVITE) becomes specified.

[Ballot discuss]
This document does a nice job hightlighting confidentiality requirements when
exchanging the a=crypto attribute, but does not adequately highlight the
corresponding requirement for integrity protection for the a=key-mgmt
attribute.

Two small changes could address this issue.  First, in section 3.4, Example 1
should note that an integrity protected channel was required to support the
security negotiations.  (Examples 3-5 share that requirement, but I would hope
that careful wording in Example 1 could keep us from repeating ourselves.)
More importantly, the security considerations section needs some text about
integrity protection with an explicit pointer to the security considerations in
RFC 4576.

[Ballot discuss]
This document does a nice job hightlighting confidentiality requirements when
exchanging the a=crypto attribute, but does not adequately highlight the
corresponding requirement for integrity protection for the a=key-mgmt
attribute.

Two small changes could address this issue.  First, in section 3.4, Example 1
should note that an integrity protected channel was required to support the
security negotiations.  (Examples 3-5 share that requirement, but I would hope
that careful wording in Example 1 could keep us from repeating ourselves.)
More importantly, the security considerations section needs some text about
integrity protection with an explicit pointer to the security considerations in
RFC 4576.

[Ballot discuss]
This document does a nice job hightlighting confidentiality requirements when
exchanging the a=crypto attribute, but does not adequately highlight the
corresponding requirement for integrity protection for the a=key-mgmt
attribute.

Two small changes could address this issue.  First, in section 3.4, Example 1
should note that an integrity protected channel was required to support the
security negotiations.  (Examples 3-5 share that requirement, but I would hope
that careful wording in Example 1 could keep us from repeating ourselves.)
More importantly, the security considerations section needs some text about
integrity protection with an explicit pointer to the security considerations in
RFC 4576.

[Ballot comment]
This document does a nice job hightlighting confidentiality requirements when
exchanging the a=crypto attribute, but does not adequately highlight the
corresponding requirement for integrity protection for the a=key-mgmt
attribute.

Two small changes could address this issue.  First, in section 3.4, Example 1
should note that an integrity protected channel was required to support the
security negotiations.  (Examples 3-5 share that requirement, but I would hope
that careful wording in Example 1 could keep us from repeating ourselves.)
More importantly, the security considerations section needs some text about
integrity protection with an explicit pointer to the security considerations in
RFC 4576.

[Ballot comment]
Please consider the comments offered by Ben Campbell in his
  Gen-ART Review.  The review was done on 27-Aug-2007, but the
  document has not been revised since.  The review is available
  at: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-avt
  -profile-savpf-11-campbell.txt

IANA Last Call Comment:

Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters - per [RFC4566]" registry
located at

http://www.iana.org/assignments/sdp-parameters

sub-registry "proto"

Type SDP Name Reference
---- ------------------ ---------
proto
RTP/SAVPF [RFC-avt-profile-savpf-11]

We understand the above to be the only IANA
Action for this document.

IANA Last Call Comment:

Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters - per [RFC4566]" registry
located at

http://www.iana.org/assignments/sdp-parameters

sub-registry "proto"

Type SDP Name Reference
---- ------------------ ---------
proto
RTP/SAVPF [RFC-avt-profile-savpf-11]

We understand the above to be the only IANA
Action for this document.

Sent email ...

Ok - I know you are going to hate to get this email from me but there
still seems to be stuff that is pointing at the 0 m line port stuff.
I would suggest the following edits.


In Section 1.1

Remove
"Grouping of m= lines in SDP may cause
several SDP session level descriptions to define (alternatives
of) the same RTP session for the same media type."

In section 3.3.1 where you have (i.e. per m= line in SDP).
change this from "i.e." to "e.g"

Later in this section change "(e.g., for best-effort SRTP [14])" to
reference the draft-ietf-mmusic-sdp-capability-negotiation instead of
the kaplan document

Remove
If an offer contains multiple alternative profiles the answerer
MUST select exactly only one and reject the other(s), e.g., by
setting the port number in the respect m= line to 0.

In section 3.3.2 remove
To offer two or more alternative RTP
profiles for a particular media stream, the SDP description MUST
contain exactly one m= line for this media stream for each profile
and all the same transport address (IP address and port number).
The profiles SHOULD be listed in the order of preference. This is
similar to formulating an offer per section 3.3.1.

In section 3.4, example 4, remove the word "grouping" from the sentence
"Note that a future grouping mechanism will allow to explicitly"

Remove reference 14 and add references to draft-ietf-mmusic-sdp-
capability-negotiation

The 10 version of this should be good to go - was emailed Jan 25 but something weird happened and did not get in drafts directory.

State Change Notice email list have been change to jo@netlab.tkk.fi, csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com, dwing@cisco.com from csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com, dwing@cisco.com

State Change Notice email list have been change to csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com, dwing@cisco.com from csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com

It seems to me that the best path forward is to follow roughly what is in AVPF and basically remove the text on offer/answer and others things that seem largely MMUSIC topics. Thoughts? Right now the text seems to normatively conflict with some of the way we might choose to solve profile negotiation.

This draft still has substantial text on alternatives and how they are negotiated. Given this is a topic with at least two drafts being discussed in the next mmuisc meeting, I'm very uncomfortable with an AVT document making normative statements about it. I would like to talk about this at the next IETF and see what happens in MMUSIC.

State Change Notice email list have been change to csp@csperkins.org, carrara@kth.se, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com from csp@csperkins.org, magnus.westerlund@ericsson.com, roni.even@polycom.co.il, taylor@nortel.com,  jf.mule@cablelabs.com

I had no concerns with the parts about combining SAVP and AVPF to form SAVPF.

I do have concerns about how the multiple profiles may be offered in SDP under offer/answer. I'd like to talk about this and understand it better. It seemed like in some cases this was changing the semantics of how something that did not understand this specification would tread these. It also seemed to be a big problem that it requires a group mechanism, normatively references fid, then points out fid done not have the right semantics.

I am also concerned that this draft is trying to define a way to offer both encrypted and unencrypted media streams but has not addressed many of the requirements that were raised around that issue. It was not clear that a draft dealing with allowing a AVPF feedback in a SRTP session needed to also resolve the issue of offering both SAVP and AVP.

In the security section dealing with two times pads, I think that changing the master key MAY be reused if SSRC are unique runs the risk that because it is MAY implementer may think they can ignore it. Might be better to rephrase as something like master keys "MUST NOT" be reused if the SSRC are not known to be unique.

I was surprised to see the how many packets could use a given key was defined in this draft - I would have hoped that was SRTP but I did not go check to see.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

It has received adequate review, by key WG members in AVT and MMUSIC.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

No issues.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Strong consensus from interested parties.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs, where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. There are reference to drafts, however these
are either in the RFC-editor queue or already with the IESG for approval.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This memo specifies an RTP profile that combines the features of SRTP
(SAVP) and the Extended Profile for RTCP-based Feedback (AVPF). Thus
allowing SRTP's security functions, encryption and integrity protection
to be used in session which requires more timely RTCP feedback than what
AVP provides. Rules for how multiple profiles may be offered in SDP
under offer/answer are also defined.

* Working Group Summary

There is consensus in the WG to publish this document.


* Protocol Quality

The combination of the two profiles are basically orthogonal. Thus no
new algorithms or other advanced features was needed to be define for
this profile. The main new functionality is the signalling solution
which has been reviewed both in AVT and MMUSIC.