Re: [Drip] 64bit comments on draft-moskowitz-drip-uas-rid-06.txt

[Robert Moskowitz <[e-mail]>]

On 9/16/20 8:24 AM, Alexandre Petrescu wrote:
>
>
> Le 16/09/2020 à 14:18, Robert Moskowitz a écrit :
>>
>>
>> On 9/16/20 4:42 AM, Alexandre Petrescu wrote:
>>>
>>>
>>> Le 15/09/2020 à 18:21, Card, Stu a écrit :
>>>> Musings...
>>>>
>>>> I actually worry about driving the probability of hash collision 
>>>> too low:
>>>
>>> We can drive the probability of hash collisions up by reducing the 
>>> prefix size, and implicitly increasing the IID size, from 64 to 65 
>>> for example.
>>
>> The hash size will most likely be on nibble boundaries.  So 64 or 68 
>> or 72.
>
> It is indeed easier to fit the bit boundaries on the underlying 
> computing architecture.  It is easier for programmmers.
>
> But there are so many such architectures, and so many IP addressing 
> architecture constraints in deployment (e.g. if ISP gives me a /57 
> because they so wish I think I have much interest in not wasting any 
> intermediary bit just to accommodate an RFC assumption).
>
> Ideally, one would make these IID and prefix lengths just parameters 
> that would work anywhere between 0 and 127.

In the next rev of drip-uas-rid, I plan on making the ORCHID algorithm 
completely parameterized.  Then let a specific deployment model provide 
what is used.

However, the decoding rules have to be 'obvious' from the HHIT. Right 
now it is based on Prefix value.  And if prefix sizes are all over the 
map, how will an implementation determine the decoding rule?

So there are limitations on the ORCHID construction due to ORCHID 
deconstruction...

For example a HHIT receiver MUST be able to decode it to get the RRA/HDA 
values for retrieval purposes.  And 'obviously' the OGA...

Bob

>
> Alex
>
>>
>>>
>>> Alex
>>>
>>>  having dealt with too many software development managers, I am
>>>> certain that some of them will dismiss very low probability 
>>>> collisions as not worth costly programmer time to address. :-(
>>>>
>>>> I am more interested in expanding the HIT Suite / OGA ID to provide 
>>>> greater crypto agility, to deal with future actual or feared 
>>>> compromise (inc. by quantum methods) of current cryptosystems.
>>>>
>>>> We could also consider a 3 level or flexible hierarchy, although 
>>>> this would be more challenging WRT parsing structure w/variable 
>>>> length fields.
>>>>
>>>> On Tue, Sep 15, 2020, 9:59 AM Robert Moskowitz 
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>
>>>>     On 9/13/20 7:39 PM, Stuart W. Card wrote:
>>>>>     Although I know how variable encodings create work for 
>>>>> programmers,
>>>>>     which means more opportunities for error, I would love to be 
>>>>> able to
>>>>>     expand some of these fields if IANA were to give us a shorter 
>>>>> prefix =>
>>>>>     larger space.
>>>>
>>>>     I did some sketches and then some calculations.
>>>>
>>>>     Prefix size    Hash size    .01% coll.    1% coll.
>>>>
>>>>     28            64            63M        663M
>>>>     24           68            250M       2.5B
>>>>     20           72            1B          10B
>>>>
>>>>     And remember, this is for a single HDA.
>>>>
>>>>     A /28 is OK, but that would mean expect collisions for some 
>>>> HDAs and
>>>>     reuse over time.
>>>>
>>>>     With a /20, it will be the exceptional HDA that needs to deal with
>>>>     collisions unless HHITs are never removed.  FedEx and UPS could
>>>>     easily re-ID each of their UAs everyday for years.  even for each
>>>>     delivery.
>>>>
>>>>     I don't think I will have time to rework the draft before the
>>>>     Interim.  I have too much to do for ICAO as well.  Plus the 
>>>> Holidays
>>>>     start this weekend.  But I will look at how to rework the draft 
>>>> for
>>>>     differing prefix and hash sizes.
>>>>
>>>>>     On 9/9/2020 9:20 AM, Robert Moskowitz wrote:
>>>>>>     Alex,
>>>>>>
>>>>>>     Interesting recommendation.  I am going to 'park' this 
>>>>>> comment and see
>>>>>>     what others say.  For now I will leave things as is. Variable 
>>>>>> encoding
>>>>>>     has to be decoded.  How do I designate that in the HHIT?  
>>>>>> Needs lots of
>>>>>>     thought.
>>>>>>
>>>>>>     Bob
>>>>>>
>>>>>>     On 9/9/20 9:14 AM, Alexandre Petrescu wrote:
>>>>>>>     I would like to suggest that the draft uses a 
>>>>>>> variable-length stance
>>>>>>>     when needing to talk about limits within addresses.
>>>>>>>
>>>>>>>     E.g. instead of hardcoding a 64bit limit in an ORCHID hash, 
>>>>>>> rather
>>>>>>>     make it variable: be it 65, or 35bit hash.
>>>>>>>
>>>>>>>     'Pre-image' - yes, attacks.  I must say that I do not know 
>>>>>>> what it
>>>>>>>     means.  Maybe one knows that better.
>>>>>>>
>>>>>>>>       A HHIT is built from the following fields:
>>>>>>>>
>>>>>>>>         *  28 bit IANA prefix
>>>>>>>>
>>>>>>>>         *  4 bit HIT Suite ID
>>>>>>>>
>>>>>>>>         *  32 bit Hierarchy ID (HID)
>>>>>>>>
>>>>>>>>         *  64 bit ORCHID hash
>>>>>>>     Consider that SLAAC might put a 65 plen in an RA, at which 
>>>>>>> point the
>>>>>>>     Drone might need to form an IID of length different than 64, 
>>>>>>> which
>>>>>>>     might need to contain an ORCHID.  That ORCHID is probably 
>>>>>>> not of
>>>>>>>     length 64.
>>>>>>>
>>>>>>>     This is what I think I am suggesting.
>>>>>>>
>>>>>>>     I am aware that if one wants to do this non-64 ORCHID then 
>>>>>>> it might
>>>>>>>     probably need to modify many other Identity and ORCHID RFCs, 
>>>>>>> and that
>>>>>>>     other parts of this I-D might also contain 64bit limits 
>>>>>>> (that I think
>>>>>>>     of as artificial).  Still, I think I am suggesting it that 
>>>>>>> way...
>>>>>>>
>>>>>>>     Alex
>>>>>>>
>>>>>>>
>>>>>
>>>>