[secdir] Secdir review of draft-ietf-dart-dscp-rtp-07

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 16 October 2014 13:20 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4FB121A1BB0; Thu, 16 Oct 2014 06:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HDyuNV1EMGEJ; Thu, 16 Oct 2014 06:20:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A621A1BA7; Thu, 16 Oct 2014 06:20:51 -0700 (PDT)
Received: from (EHLO lhreml405-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP73405; Thu, 16 Oct 2014 13:20:50 +0000 (GMT)
Received: from szxeml459-hub.china.huawei.com ( by lhreml405-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 16 Oct 2014 14:20:49 +0100
Received: from szxeml557-mbs.china.huawei.com ([]) by szxeml459-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 21:20:47 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: " draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-dart-dscp-rtp-07
Thread-Index: AQHP6UP+vVL5nBAJ0EG0mQJHJZkKjg==
Date: Thu, 16 Oct 2014 13:20:46 +0000
Message-ID: <2415CF56-6C71-45B6-87DE-C7907C59E73C@huawei.com>
References: <AEBDE45E-963A-47B5-997F-416562FE1B32@inria.fr>
In-Reply-To: <AEBDE45E-963A-47B5-997F-416562FE1B32@inria.fr>
Accept-Language: en-US, zh-CN
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_2415CF566C7145B687DEC7907C59E73Chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/IZmxZk0ZH1LOW8Pvad8R6ra05ss
Cc: IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Secdir review of draft-ietf-dart-dscp-rtp-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 13:20:58 -0000

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

IMHO, the document is almost ready. I just have minor comments:

** Technical **

* Page 6:
For IPv6, addition of the flow label [RFC6437] to network 5-tuples
results in network 6-tuples, but in practice, use of a flow label is
unlikely to result in a finer-grain traffic subset than the
corresponding network 5-tuple (e.g., the flow label is likely to
represent the combination of two ports with use of the UDP

The flow label is different in each direction. Hence, if anything, you
should talk about 7-tuples rather than 6-tuples.

* Page 6, Section 2.2:

What about the drawbacks of multiplexing? -- You don't describe any.
What about Head of Line blocking?

* Page 13, Section 5.1:

When a protocol that provides reliable delivery receives a packet
other than the next expected packet, the protocol usually assumes
that the expected packet has been lost and respond with a
retransmission request for that packet.

Note: There is no "retransmission request" in TCP. Aditionally:

* Page 13, Section 5.1:
This should not be done for current transport protocols within a
single network 5-tuple, with the exception of UDP and UDP-Lite.

This text is rather confusing. Maybe rephrase as "This should not be
done for transport protocol instances of current protocols, except of
UDP and UDP-Lite"?

* Security considerations section

Maybe Section 3.3 of RFC 6274 wuld be of use here?

** Nits/Editorial **

* Page 2:

The results of using multiple DSCPs to obtain different QoS
treatments within a single network 5-tuple (e.g., reordering) have
transport protocol interactions, particularly with congestion
control functionality.

Please "(e.g., reordering)" right after "treatments".

* Page 2:


* Page 3:
Please add references for VP8 and H264

* Page 5:
RTP is usually carried over a datagram protocol, such as
UDP[RFC0768], UDP-Lite [RFC3828] or DCCP [RFC4340]; UDP is most
commonly used, but a non-datagram protocol (e.g., TCP) may also be

Add missing space in "UDP[RFC0768]".

* Page 6:
When TURN selects use of TCP, the entire real-time communications
session is carried over a single TCP 5-tuple.


* Page 8, Section 3:
The DiffServ architecture[RFC2475] maintains distinctions among:

Please add the missing space

* Page 8:

* Page 11, Section 3.2:
Better results may be achieved when DSCPs are used to spread traffic
among a smaller number of DiffServ-based traffic subsets or
aggregates, see [I-D.geib-tsvwg-diffserv-intercon] for one proposal.

Please put the "see [I-D..]" within parenthesis.

* Page 13, Section 5.1:
Reordering also affects other forms of congestion control, such as
techniques for RTP congestion control that were under development
when this memo was published, see [I-D.ietf-rmcat-cc-requirements]
for requirements.

Please put the "see [I-D..." within parethesis -- i.e. "(see [I-D..)".

* Page 17, section 5.4:

Please expand this acronym.

* Page 18, Section 6:
, see Section 5.2 above.

Please put this text within parenthesis.

Thank you,