On 04/22/2018 07:12 PM, Dale R. Worley wrote:
> My apologies for not responding to this sooner:
>
> Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx> 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.)
Sorry, I should have pasted the text. But the point is moot, see below.
>
> 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.
I did some research and you were right, starting from the left side is more common. My main counter-example is in fact in STUN itself as figure 3:
0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
And as the base64 encoding is done on an array of bytes and not an integer, it is in fact simpler to define it that way. The new text in section now reads:
Bits are assigned starting from the most significant side of the bit
set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit.
I also updated the example in Appendix B.1.
--
Marc Petit-Huguenin
Email: marc@xxxxxxxxxxxxxxxxxx
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature
