Re: [HAM-AG] [IPv6] Request for feedback: draft-evan-amateur-radio-ipv6

[Alexandre Petrescu <[e-mail]>]

Le 16/02/2023 à 01:10, Nick Harper a écrit :
> Why hash the callsign at all?

I think it is a good question.

There appears to be a need of having the callsign in IID.  Maybe one can
understand better the need - the use-case?  Maybe I need to read better
the draft to guess better the details of the use-case.

The technique of converting by using hashing and security functions is
often a great temptation, due to many of their advantages.  It is
tempting also because it is a mechanism, software is available,
algorithmics are attractive.  It can be made work soon and declare great
satisfaction.  That can bring great deployment success, some times.

Sometimes one wants to convert and make sure there is uniqueness
guarantee, other times one wants to sign, to prove ownership, and so on.
  For example, in today's context one would query a balloon - call a sign
- to whom might it belong, and the answer would need to be
authoritatively proven right.

On another hand, many of the requirements might be contradictory.

For example, a question can be made as to why should one use a hashing
function that provides only uniqueness (no ownership) if the callsign is
unique in the first place, being allocated centrally; and the entire IP
address has a unique prefix too, allocated centrally.

So, why using a hashing function if there is already uniqueness?

> Article 19 of ITU's Radio Regulations specifies the format of 
> callsigns, and they are at most 7 characters long. The ASCII 
> representation of the callsign

8bit ASCII?  Unicode?  Should ITU upgrade?

> could be used to generate 7 bytes (56 bits) to use in the address 
> without needing any hashing.

That might make sense, but again, what kind of ASCII?

> For the exception in 19.68A (on special occasions, for temporary use,
> callsigns could be longer than 7 characters), a 6-bit encoding scheme
> could be devised so that alphanumeric callsigns up to 10 characters
> long could be encoded in 60 bits.

10 characters in 60 bits sounds as if there is compression.  It should
be 80 bits for easy readability (each char on 8bit).

This kind of compression can exist ok for computers, but for humans it
might be more difficult to read.  For example, ASN.1 representation in
CAM message in vehicles represent a nightmare for many developpers,
because of a similar compression. What goes well there is xml
representation that many more can read.

But I agree with the possibility of a 6bit encoding scheme.

For me, if I were to devise it, I would like a result like this:

VA3ZZA -> 2001:db8::8A:322A (remark VA3ZZA is 8A:322A, which seems
relatively a same, visually)

In order to be almost a same, verbally on the spelling alphabet, one
would need a 37-decimal representation of an IP address (and not just
the current 16-decimal - hexadecimal - representation).  Such a
37-decimal representation of an IPv6 address would be needed to be
developped independently.  With it, it would allow a conversion of the form:

VA3ZZA -> 2001:db8::VA3ZZA

That would be an ideal conversion, from a readability standpoint.

Finally, I wanted to say that the proposed method in the draft also
proposes to use a 'Node ID', like this: "Use the final 4 bits of the
address' Interface Identifier to store the nodes's ID number."

Not sure whether it is a good idea, probably yes.

Probably this 'node ID' is like the interface number concept: an address
is given to a computer, but that computer might have several interfaces,
and they are numbered.  On a regular PC they could be max 16, but on
large switches it could be 100 or even more.

Alex

> 
> On Wed, Feb 15, 2023 at 3:28 PM Donald Eastlake <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> Hi,
> 
> On Wed, Feb 15, 2023 at 3:03 PM Evan Pratten <[e-mail] 
> <mailto:[e-mail]>> wrote:
>> 
>> On Wed, Feb 15, 2023 at 2:58 PM Donald Eastlake <[e-mail]
> <mailto:[e-mail]>> wrote:
>>> I'm not sure the hash even needs to be cryptographic.
>> 
>> Agreed. I would call a cryptographic hash *undesierable*. Why
>> waste processing power hiding the callsign when you have to ID
>> yourself anyways?
>> 
>> I am admittedly far from an expert on hashing algorithms. Donald, 
>> do you have any suggestions that fit the properties you outlined
>> by chance?
> 
> Indeed, I would suggest using FNV-64 truncated to the top 60 bits, 
> See https://datatracker.ietf.org/doc/draft-eastlake-fnv/ 
> <https://datatracker.ietf.org/doc/draft-eastlake-fnv/>
> 
> Here is an article on using FNV-32 for IPv6 flow label 
> https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf
>
>
> 
<https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf>
> 
> Thanks, Donald ============================= Donald E. Eastlake 3rd 
> [phone] (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA 
> [e-mail] <mailto:[e-mail]>
> 
> -- HAM-AG mailing list [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/ham-ag 
> <https://www.ietf.org/mailman/listinfo/ham-ag>
>