[AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 23 June 2015 12:24 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A51B2BD6 for <avt@ietfa.amsl.com>; Tue, 23 Jun 2015 05:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DhlkwOJGIRjd for <avt@ietfa.amsl.com>; Tue, 23 Jun 2015 05:24:11 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D4B1B2BDA for <avt@ietf.org>; Tue, 23 Jun 2015 05:24:10 -0700 (PDT)
X-AuditID: c1b4fb30-f799f6d000000faf-27-55894fe8ca2d
Received: from ESESSHC021.ericsson.se (Unknown_Domain []) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.EA.04015.8EF49855; Tue, 23 Jun 2015 14:24:09 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Tue, 23 Jun 2015 14:24:08 +0200
Message-ID: <55894FE8.6080406@ericsson.com>
Date: Tue, 23 Jun 2015 14:24:08 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IETF AVTCore WG <avt@ietf.org>, draft-ietf-avtcore-rfc5764-mux-fixes@tools.ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPJMWRmVeSWpSXmKPExsUyM+Jvre5L/85Qg5cnGC1e9qxkt9j9JNSB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgylj+q5ut4Ll+xYevC1gaGK+qdjFyckgImEjs blnKBmGLSVy4tx7I5uIQEjjKKHHq0yV2CGc5o8STs9/BqngFtCUWvOliAbFZBFQlnj44BGaz CVhI3PzRCFYjKhAlMfXxOhaIekGJkzOfgNkiAtESCw7+YAWxhQWsJO4eWcTYxcjBwSxgL/Fg axlImFlAXqJ562xmEFsIaFVDUwfrBEa+WUgmzULomIWkYwEj8ypG0eLU4qTcdCMjvdSizOTi 4vw8vbzUkk2MwBA7uOW3wQ7Gl88dDzEKcDAq8fAu2NsRKsSaWFZcmXuIUZqDRUmcd8bmvFAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjO7yJu/k5q2Zsc64JM/v2fTySokeiz+GW1tFjAIO fE8TbJ5Wf7vuQuqD7S8iVnaHnVoexJLvL/bZ+nKQsGxpFU9T8PWgCQas4i3bjkx11eetUp9+ LSkvzeVsk+A7wYk5uuVz/F4vvDr/6e2DLBtuduyQObewV1rMqq30t+Px0m2zrXd8euXxXoml OCPRUIu5qDgRABGDsYcSAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/zOSvUi6xBmlx9OVMzy_hue_bLSo>
Subject: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 12:24:13 -0000


I did a review of draft-ietf-avtcore-rfc5764-mux-fixes-02 and have some 

A. Abstract:

It overrides the guidance from SRTP
    Extension for DTLS [RFC5764], which suffered from three issues
    described and fixed in this document.

There are four issues listed in Section 1.

B. Section 1, bullet 1 and 2:

"It implicitly allocated codepoints ..."

I am not particular happy about this formulation as it is only part of 
the truth. I think the authors should try to write a separate paragraph 
about the issue of overlapping value ranges, and the need to maintain 
the separated for any usage where multiplexing could occur. Thus this 
leading to an limitation of the usage of codepoints in the STUN/TURN as 
well as TLS protocol.

C. Section 1, bullet 4:

The current ranges are not efficiently allocated making it harder
        to introduce new protocols that might require multiplexing.

I am not quite certain what this bullet tries to really say. What is 
allocated in ranges, is the ranges available for registration that 
doesn't reserve space for future protocols, or something else?

D. Section 1:

    These flaws in the demultiplexing scheme were unavoidably inherited
    by other documents, such as [RFC7345] and
    [I-D.ietf-mmusic-sdp-bundle-negotiation].  These will need to be
    corrected with the updates this document provides.

It is unclear what the second "These" refers to, I guess "flaws" not the 

E. Section 1.1:

Also here I think the document could benefit from a more analytic and 
less confrontational language. It is better to write that "Multiplexing 
limits the available range for new STUN methods." than "... entirely 
obliterating those STUN method codepoints".

F. Section 1.2:

I want to remind the authors that this document will go to TLS WG during 
WG last call, and would recommend that one avoids to dictate to that WG 
how their situation are:

"Unlike STUN, TLS is a
    mature protocol that is already well established and widely
    implemented and thus we expect only relatively few new codepoints to
    be assigned in the future."

Considering the quite significant work ongoing on TLS, I think you might 
be wrong in this analysis.

Focus on the facts and the goal here. I think the goal is to avoid 
having future assignment of functions cause failure in the multiplexing 

G. Section 1.

I am missing a clearer description of the long term goal with this 
update. To my understanding it is to avoid future allocation in any of 
the affected protocols to result in that multiplexing becomes impossible 
when using that feature.

A second goal appear to enable the possibility that additional protocols 
should be able to be given a range for them to multiplex. I think this 
second one can result in more discussion, as there are multiple people 
that express a preference for more explicit demultiplexing.

In addition I think the method for achieving these goals should be made 
more clear. That is to make it clear in the IANA registries which values 
that are subject to risks for collisions and where coordination between 
protocols may be required. That is at least what I thought was the 
conclusion of the Dallas meeting.

H. Section 1.2:
    0-19    Reserved (MUST be allocated with Standards Action)

As I EKR commented, as these values anyway require Standards action this 
is meaningless. I think something more like (Requires coordination, see 
RFCXXXX). Where RFCXXXX is this document would be more acceptable and 
also much more informative.

This relates to what I see as the need for this document to much better 
explanation of the goals and future considerations needed to avoid 
failure in allocations.

I. Section 1.3:

    An implementation that uses the source IP address and port to
    identify TURN channel messages MAY not need to restrict the channel
    numbers to the above range.

I think we need to have discussion about this. I personally think it 
makes much more sense to not limit the other protocols due to TURN, as 
an TURN client MUST know which address the TURN server uses. Thus 
limiting TURN channel demultiplexing based on source address appears 

If I misunderstanding this, then I think this section must before giving 
any recommendation make it clear why src address is not sufficent and we 
actually want to consume part of the value space for this?

Note, I do think it is valuable to discuss TURN channels here, but I 
think it needs to reconsider what the message should be.

J. Section 1.4:

This is insufficient to explain any issues why the order of testing do 

K. Section 3:

    new values or ranges are added, they MUST be tested in ascending

I am missing the text that makes it clear how one would go about to add 
allocate a new value or range when proposing to add a new protocol.

L. Section 5.

It doesn't simply update existing registries. It does currently 
specifies that TURN channels can be demultiplexed. Are there 
implications of that?

M. Section 6:

I think all the "Reserved" messages are the wrong ones. I think they 
should say "Reserved (DTLS-SRTP multiplexing collision avoidance, see 

N. Section 6.1:

I think this needs to be more explicit about what it re-assigns. It 
needs to say that the values available for allocation i.e. 0-FFF are 
being changed to instead have the following ranges.

Then I think a resulting table for the ranges would be good.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com