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

["Card, Stu" <[e-mail]>]

Bob's points are sound, but I don't think meant to dispute Alexandre's
major point, with which I agree:

Maybe we want to add some significance to the bits, but keep it as low as
 possible.

On Thu, Sep 17, 2020, 10:28 AM Robert Moskowitz <[e-mail]>
wrote:

>
>
> On 9/17/20 9:24 AM, Alexandre Petrescu wrote:
>
>
>
> Le 16/09/2020 à 14:41, Robert Moskowitz a écrit :
>
>
>
> 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?
>
>
> That is a problem indeed.  But it might be a problem because the bits in
> the address are overloaded with significance, rather than letting them
> be used for routing and addressing exclusively.  There is an RFC that
> tells that the Significance of IPv6 Interface Identifiers - there is no
> siginificance, they are opaque.
>
>
> Read
>
> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/
>
> For the why for HITs.  They are NOT for routing.
>
> There are stack reasons behind using IPv6 address space for HITs.  HHIT
> expands on this.
>
> Maybe we want to add some significance to the bits, but keep it as low
> as possible.
>
> Also, there is this ULA space.  Maybe we want to work in the ULA space
> and crowd these bits in there exclusively.
>
> For example, a HHID IP address would be an address of the form
> fd00:a:b:c:d:publickey.  'a' and 'b' would say that this is a HHIT.  All
> the rest of the bits would be encoded the way the author wishes, but it
> would all be within this ULA 'walled garden'.
>
> Maybe there are other ways (other than ULA) to deal with the encoding
> problem you mention above.  Maybe reserve a few bits to encode the way
> to decode.
>
> But it would be good to not impose again new 64limits in the address
> space.
>
>
> Not new.  Goes back to RFC 4423 and 5201.
>
>
>
>
> Alex
>
>
> 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]> <[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
>
>
>
>
>
>
>
> --
> Robert Moskowitz
>