Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

Justin Uberti <> Thu, 24 July 2014 17:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 955791A0653 for <>; Thu, 24 Jul 2014 10:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Y78zFihHRrq for <>; Thu, 24 Jul 2014 10:32:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48ABC1A0016 for <>; Thu, 24 Jul 2014 10:32:00 -0700 (PDT)
Received: by with SMTP id hu12so5456827vcb.20 for <>; Thu, 24 Jul 2014 10:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=InZxq8x8loljA9k0bIzGYQ5xLQpmJEa3nqNx34K3lOY=; b=R0SfH/UXFwpdoeXuhHjAzUpc8oerqo2K3KzhMP3oT+sYMlPQEgjqx6eKyG9zlT54v3 kB9hzFGgAwCql18jvIws+iStjmfHdHw5gAeZyHSRyF5J6dTPaTxVNPHHX9lVUFT24eJd fuNl+CNZ+p1f5duAQ7M1eKdyIhusnpSxmG55tiXo42Oa1TI5v/Pci4m4lE/KYa0Pifx9 69PGrz9IQebBSn+IKpynpxd4MI4ezx3jjouE5Ewyy8I+pKOYKFZOPxaaYGEwY4ihi6ZG AM4L/1KbEOjPDNrjwU3SvphcpCNRL72q1jmzC+EjraQNLWBn2j/88geKmQFd7/eOkEhQ w4/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=InZxq8x8loljA9k0bIzGYQ5xLQpmJEa3nqNx34K3lOY=; b=gOZ1UudSGvJUWPBjvgP4zQDBLscO7ykZlT+I5eOwNb/HzJFiVqLqOs1wA7i01C4rBh EkaetIipFKgIvDvQfCKJp9xXoGkJ4dN5vjNERfw2ibKvZaP8CHyFwZtky5n1DlqNDXi+ VvonO/N+FcDXmrMryZrTdIf3h4eQYIzrfgDNIz5DeBSoYb7KF17176Cse7y9kEZFrQ21 Dot6JpSuOqENbnT6o+s+wSWT9L8efwxN/6QOfagP/uoao+6nT+ikE3vEei4jaITnp9+E mlqKZCW/8YgvcZOhCkOR8zGqGv1HB99hvy8C3it9b2WF7g+Fvos7z0ImD/EU9abBxJk8 taKQ==
X-Gm-Message-State: ALoCoQncyRITAMGsMI04tOQ7sVLQTJ3fs4EUxc0HhLiVLLnIiEesAwVzrO9iu9UCFHdm/K+ut9s0
X-Received: by with SMTP id t10mr14642511vcf.34.1406223119459; Thu, 24 Jul 2014 10:31:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Jul 2014 10:31:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Justin Uberti <>
Date: Thu, 24 Jul 2014 13:31:39 -0400
Message-ID: <>
To: "Cullen Jennings (fluffy)" <>
Content-Type: multipart/alternative; boundary=089e0163412c82cdec04fef3d5fb
X-Mailman-Approved-At: Fri, 25 Jul 2014 09:10:23 -0700
Cc: "" <>, "" <>, "" <>
Subject: Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 17:32:01 -0000

I just sent a message to the TRAM list on this - I think the only real
issue here is that the STUN demux procedure specific in 5764 is incorrect.
When FINGERPRINT is used, which is mandatory for ICE, there is no issue
with demuxing STUN from anything.

And there has never been a demux issue for TURN channels, since packets
from the TURN server will never be unencapsulated.

Ergo, we don't need any changes to the STUN registries or TURN channels. We
should just update 5764 to reference 5389, Section 7.3.

I agree it would be nice to have a first-byte registry for generic data,
e.g. RTP vs DTLS, to ensure that all application protocols can be properly
demuxed from each other.

On Wed, Jul 23, 2014 at 1:54 PM, Cullen Jennings (fluffy) <>

> Thank you for doing this - I’ve wanted to have this fixed for a long time.
> I think this is good but some recommendations I would make.
> We should make a new IANA registry that keeps track of for each value of
> the first byte, which protocol it is allocated to. I would suggest that it
> require "Standards Action” to allocate a new code point to a protocol but
> of course one allocated to that protocol, the protocol would manager it
> within it’s existing IANA registry for that protocol with that protocols
> existing rules.
> The advantage of this is we can allocate the points as needed instead of
> guessing if TLS or STUN  or some new protocol will need a given number
> points. There is no implementation problem for the demux because things
> that use the new code points would know how to demux them.
> I think that STUN and TURN should use up the minimal number of code points
> in the registry that they easily can. Later, if they need more code points,
> they can co back registry to get more.
> I would suggest that 256 channels would be enough for TURN. If a given
> TURN client needs more than that, it just needs to allocate a second local
> UDP port. So TURN probably needs 1 code point for now.
> It would be good to allocate one code point for experimental use.
> _______________________________________________
> tram mailing list