Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 (Dale R. Worley) Mon, 23 April 2018 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 114BD1270FC for <>; Sun, 22 Apr 2018 19:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Q8PVl_NSTj5 for <>; Sun, 22 Apr 2018 19:12:34 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6BDE12711B for <>; Sun, 22 Apr 2018 19:12:33 -0700 (PDT)
Received: from ([]) by with ESMTP id AQy0fZWmHnpflAQy0fuP7L; Mon, 23 Apr 2018 02:12:32 +0000
Received: from ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by with SMTP id AQxwfN23TmHJVAQxxfcyJT; Mon, 23 Apr 2018 02:12:31 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id w3N2CRm8028862; Sun, 22 Apr 2018 22:12:27 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id w3N2CQte028857; Sun, 22 Apr 2018 22:12:26 -0400
X-Authentication-Warning: worley set sender to using -f
To: Marc Petit-Huguenin <>
In-Reply-To: <> (
Date: Sun, 22 Apr 2018 22:12:26 -0400
Message-ID: <>
X-CMAE-Envelope: MS4wfBDBfvEX9SjLHp5Zp4ymCroEKvavrnu71N+s32ouA5tgbYagB0ZKANHHLppmGxT3LPtH0kqc71ei9+PIcP8aYlvCz2/g/3xqaij9z+TuxwQ9mNFP3K45 QARJHP4dhzi2NGmUsil5tL+Qx/y4+5oEY3r51XZuqgZIa5AKtT9d0kcnLsW+9ul1eJtSUnvDfya1vnrJ6FaRfDRRxGJt4N6n6LJmT3834A31qClVPbhf62ag dkeeNOAa+QLKigTY5WlvFRuvd6Fsplo891Bkm7xjKhTyJEYvCkqWLnW6bp2THUfr
Archived-At: <>
Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Apr 2018 02:12:36 -0000

My apologies for not responding to this sooner:

Marc Petit-Huguenin <> writes:
>> 17.1.  STUN Security Features Registry
>>    A STUN Security Feature set defines 24 bit as flags.
>>    IANA is requested to create a new registry containing the STUN
>>    Security Features that are protected by the bid down attack
>>    prevention mechanism described in section Section 9.2.1.
>>    The initial STUN Security Features are:
>>    Bit 0: Password algorithms
>>    Bit 1: Username anonymity
>>    Bit 2-23: Unassigned
>> Beware that the assignment of features to bits in the security feature
>> value has changed!  Bit numbers are assigned from the left/high-order
>> end -- see figure 2 in the draft.  So the *values* for these bits are:
>> 0x400000   Bit 0: Password algorithms
>> 0x200000   Bit 1: Username anonymity
>> But the values assigned in -15 were:
>>    0x000001: Password algorithms
>>    0x000002: Username anonymity
> Hmm, that was not the intent, and not how I read the text. Even in
> Figure 2 less significant bits are on the right.  So the intent is
> real tat bit0=0x001, bit1 = 0x002, and so on.  All we do is about
> interoperability, so I added some text that makes that less ambiguous.

(The latest posted version is still -16, so I haven't seen the changes
you refer to.)

In reference to the statements:

>>    The initial STUN Security Features are:
>>    Bit 0: Password algorithms
>>    Bit 1: Username anonymity
>>    Bit 2-23: Unassigned

I've skimmed the text again, and it appears that this passage is the
only one that allocates the functions "password algorithms" and
"username anonymity" to specific bits of the security feature value.
Thus, it's critical what "bit 0" means in this context.

Searching for "0" in the document, I can find no outright definition of
the meaning of "bit 0".  However, there are 10 figures in the document,
and 8 of them show the numbering of the bits of various fields, with bit
"0" being the *high-order*, *most-significant*, "left"-most bit of the
field, bit "1" the next-highest-order bit, etc.  This numbering seems to
be conventional in RFCs.

Thus, I recommend that if you really want to persist in calling the
low-order bit of the security features field "bit 0", you should explain
that very clearly in section 17.1.