Duplication Delay Attribute in the Session Description Protocol
draft-ietf-mmusic-delayed-duplication-03

[Ballot comment]
Thank you for addressing my concern.

Within the new text, "Lucky13" does not have a reference and I think it needs one (or that second example in the sentence being removed).

[Ballot comment]

Thanks for handling my discuss. I think you need a
reference for Lucky13 - see [1] where'll you'll find
that.

[1] http://www.isg.rhul.ac.uk/tls/Lucky13.html

---- old comments below, I didn't check them

- The ABNF allows for infinite numbers of delays and
infinitely large delays. Wouldn't it be better to limit
both?

- The fact that "a=duplication-delay: 50 100" means that
the 2nd re-tx is 150 ms after the initial tx is only
explained in the 2nd example and you never say that
otherwise. That could lead to interop problems since my
initial assumption would have been that the 2nd re-tx
would be 100ms after the initial tx for the above
example. I think you should say something about that in
section 3.

- What if the delay indicated is less than a packet, say
if every packet has 20ms of media but 5ms is indicated
in the SDP?

[Ballot discuss]

Updated with suggested text. Having thought about
this a bit more, I don't expect its really feasible to
get a full analysis done here since this mechanism
might only badly interact with cryptograpic schemes
that are already somewhat weak. So I suggest
adding 2 chunks of text such as those below
to the security considerations section.

Note: I'm more confident of the language for
chunk#1, please sanity-check chunk#2 before
you include it with someone who knows a
bit more about SDES.

Chunk#1:

"Since this mechanism causes duplication of
media packets, if those packets are also
cryptographically protected, (e.g. encrypted)
then such duplication could act as an accelerator
if any million-message [RFC 3218] or similar
[Lucky13] attack exists against the security
mechanism that is in use. Such acceleration
could turn an otherwise infeasible attack into
one that is practical, however, assuming that
the amount of duplication is small and that
such weak or broken security mechanisms
should really not be used, the overall security
impact of the duplication should be minimal.

If however, a bad-actor were in control
of the SDP but did not have access to the
keying material used for media, then
such a bad actor could potentially use
the SDP to cause the media handling to
use a weak or broken mechanism with
a lot of duplication, in which case the
duplication could be significant. Deployments
where the SDP is controlled by an actor
who shouldn't have access to the
media keying-material should therefore
be cautious in their use of this
duplication mechanism."

Chunk#2

"If this mechanism were used in
conjunction with SDES and if the key
being used for media protection is
derived from a human-memorable
or otherwise dictionary-attackable
secret, then the duplication done
here could allow for a more efficient
dictionary attack against the media.
The right countermeasure is to use
proper keying, or if using SDES
to ensure that the keys used are
not dictionary-attackable."

[Ballot comment]

- The ABNF allows for infinite numbers of delays and
infinitely large delays. Wouldn't it be better to limit
both?

- The fact that "a=duplication-delay: 50 100" means that
the 2nd re-tx is 150 ms after the initial tx is only
explained in the 2nd example and you never say that
otherwise. That could lead to interop problems since my
initial assumption would have been that the 2nd re-tx
would be 100ms after the initial tx for the above
example. I think you should say something about that in
section 3.

- What if the delay indicated is less than a packet, say
if every packet has 20ms of media but 5ms is indicated
in the SDP?

[Ballot discuss]
I think that this draft needs to provide guidance on appropriate use cases. I can imagine some, for example during mobile device handover, but I think the authors really need to discuss or otherwise refer to the use cases, and describe how the sender knows that it is in a situation where it should burn the additional network bandwidth using this method.

[Ballot comment]
Section 1:
"Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion"
Like Benoit, I agree that this sentence is confusing.  Do you really mean something like the following?
"""
Delayed duplication (or duplication at all) is harmful in cases where the primary cause of packet loss is congestion, rather than network than a network outage due to a temporary link or network element failure.  Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means.
"""

[Ballot discuss]
  Furthermore, delayed
  duplication must not be used in cases where the primary cause of
  packet loss is congestion, rather than a network outage due to a
  temporary link or network element failure.  Duplication can make
  congestion only worse.

I'm missing something. What is the use case?
I don't know of any operators who would say: I know I have some temporary link or network element failures, but this is not my absolute highest priority, so let me focus on this mmusic-delayed-duplication trick instead.
Also, what kind of temporary link or network element failure would be solved below a reasonable duplication delay, where my guess is that we speak about seconds, right?
I see that you wrote:

  In this specification, we are not concerned about how the sender
  should determine the duplication delay.

Bottom line: from an operation point of view, I have no clue when to apply this specification.

[Ballot comment]
1. Compared to draft-ietf-mmusic-duplication-grouping, do I understand correctly the packets are sent over the same path in this document, and across different ones in draft-ietf-mmusic-duplication-grouping? If yes, please specify it.

2. Like https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ballot/#benoit-claise, the equivalent section in both drafts would be ideal.
Note that the answer to the point 1 will determine if "The impact on routing" should be present. I guess no.

3. "In the second example below, the multicast stream is duplicated twice."
Duplicated twice seems funny, at least with my French speaking background.

[Ballot discuss]

This may be obvious to SDP folks but if the media are
cryprographically processed does the duplication happen
before or after the crypto?  I assume its before, as it'd
otherwise be a layering pain. Is that right?

Anyway, the discuss is: has someone looked at how this
might interact with security for media?  For example,
did anyone think about whether this kind of duplication
could give an attacker who could manipulate the SDP but
not the media an advantage since that attacker could
affect the plaintext in deterministic ways. Or if SDES
is used with a human memorable string as a key and if
the media were essentially random, then this would give
a dictionary attacker a nice quick way to verify guesses
of the key. I'm not sure what security considerations
text ought be added though, since you'd want someone
who's much more familiar with SRTP options etc.  to
have done that analysis first. And the answer might come
out the same as well - that there's no real change worth
noting.

[Ballot comment]


- The ABNF allows for infinite numbers of delays and
infinitely large delays. Wouldn't it be better to limit
both?

- The fact that "a=duplication-delay: 50 100" means that
the 2nd re-tx is 150 ms after the initial tx is only
explained in the 2nd example and you never say that
otherwise. That could lead to interop problems since my
initial assumption would have been that the 2nd re-tx
would be 100ms after the initial tx for the above
example. I think you should say something about that in
section 3.

- What if the delay indicated is less than a packet, say
if every packet has 20ms of media but 5ms is indicated
in the SDP?

[Ballot comment]
-- Section 3 --
Where does the new ABNF production, "delaying-attribute", fit into other ABNF?  Should this be extending an existing ABNF element to add "delaying-attribute" as a new possible value (from a formal ABNF point of view)?

Is a dupliation delay of 0 semantically valid?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mmusic-delayed-duplication-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the att-field (both session and media level) registry in the Session Description Protocol (SDP) Parameters page at

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

The following attribute will be registered:

Type: att-field (both session and media level)
SDP Name: duplication-delay
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed by IANA upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Delayed Duplication Attribute in the Session Description Protocol) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Delayed Duplication Attribute in the Session Description Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A straightforward approach to provide protection against packet
  losses due to network outages with a longest duration of T time units
  is to simply duplicate the original packets and send each copy
  separated in time by at least T time units.  This approach is
  commonly referred to as Time-shifted Redundancy, Temporal Redundancy
  or simply Delayed Duplication.  This document defines an attribute to
  indicate the presence of temporally redundant media streams and the
  duplication delay in the Session Description Protocol.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO Writeup for draft-ietf-mmusic-delayed-duplication-02

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard. The title page notes the document as Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  A straightforward approach to provide protection against packet
  losses due to network outages with a longest duration of T time units
  is to simply duplicate the original packets and send each copy
  separated in time by at least T time units.  This approach is
  commonly referred to as Time-shifted Redundancy, Temporal Redundancy
  or simply Delayed Duplication.  This document defines an attribute to
  indicate the presence of temporally redundant media streams and the
  duplication delay in the Session Description Protocol.


Working Group Summary

  There is WG consensus behind this draft. All issues raised during
  and before WGLC have been addressed.


Document Quality

  The document has received reviews from working group participants
  both at MMUSIC and AVTEXT and the document shepherd.  There is
  currently at least one vendor implementing this mechanism and
  various other vendors have expressed interest for this technique.


Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

  Ari Keranen is the Document Shepherd, and the Responsible Area
  Director is Gonzalo Camarillo.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd has reviewed the past two versions of the
document and believes the document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No need for any such review.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, the shepherd has received confirmation from all authors.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no filed IPR disclosures for this document.


(9) 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? 

  There seems to be good consensus on the current document by the WG,
  which seems to understand and agree with it.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Idnits complains about possibly incorrect name for
draft-ietf-mmusic-duplication-grouping and therefore possible
downref. The reference is however correct and there is no
downref. Idnits also complains about RFCXXXX references that will be
fixed by RFC editor.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document provides extensions to SDP only and as such the
  necessary review has already been done by the MMUSIC WG.


(13) Have all references within this document been identified as
either normative or informative?

Yes, all references are classified as either normative or informative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There is no such dependency. The only normative reference in draft
  state is advanced at the same time.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The publication of this document will not change the status of any
  existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA Considerations section has been reviewed and no issues found.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new IANA registries defined by this document.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ABNF in section 3 was checked with the Bap tool and appears to
  be correct.