Re: [Hipsec] clarification on HIT Suite IDs

[Francis Dupont <[e-mail]>]

Tom Henderson writes:
> In the course of performing recent draft revisions, I had some 
> additional questions about the HIT Suite IDs.
> 
> http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19#section-5.2.10

=> HIT/ORCHID stuff is more in section 3 and appendix E.

> Briefly, RFC 7343 specifies that ORCHIDs consist of the special prefix, 
> a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash.

=> yes.

> RFC 7343 does not ask IANA to set up a registry for OGA values.

=> yes and the reason is OGA values are not globally defined: they
are related to a Context ID (HIP in this case).

> The RFC states 
> "... the value of the OGA identifier according to the
>     document defining the context usage identified by the Context ID." 
> My read of this is that the assignment of OGA identifiers is delegated 
> to the documents defining the context usage identified by the Context 
> ID; in this case, it would be RFC5201-bis.

=> exactly.

> The HIT Suite ID in RFC5201-bis is used as the OGA ID in HIP.  The IANA 
> considerations section states this, although someone looking explicitly 
> for assigned OGA values may have to dig for it.

=> section 3.2 says:

   ... The set of hash function, signature algorithm, and the
   algorithm used for generating the HIT from the HI depends on the HIT
   Suite (see Appendix E) and is indicated by the four bits of the
   ORCHID Generation Algorithm (OGA) field in the ORCHID.

so the OGA table is in the appendix E (note the appendix E itself
was a bit broken in previous RFC 5201 bis versions, but there was
such a table in it).

> The reason that the HIT Suite ID is not named the 'OGA ID' in HIP is due 
> to the potential growth capability that is defined in section 5.2.10. 
> Specifically, the zero value for HIT Suite ID is reserved, to allow for 
> growth of the field should the four-bit field be exhausted.  So it 
> technically is an 8-bit value, and the 4 higher-order bits are used to 
> form the OGA (for now).
> 
> Basically, the draft is saying that if HIT Suite ID is zero, then this 
> ORCHID encoding:
> 
>   ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )
> 
> becomes instead:
> 
>   ORCHID     :=  Prefix | HIT Suite ID | Encode_92( Hash )
> 
> and the bits immediately after the Prefix are used also to identify the 
> length of this OGA ID.  It seems to me that this could either be 
> clarified further in the draft, or simplified.

=> no, it doesn't say that: the current wording is:

   The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
   opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
   This difference is a measure to accommodate larger HIT Suite IDs if
   the 16 available values prove insufficient.  In that case, one of the
   16 values, zero, will be used to indicate that four additional bits
   of the ORCHID will be used to encode the HIT Suite ID.  Hence, the
   current four-bit HIT Suite-IDs only use the four higher order bits in
   the ID field.  Future documents may define the use of the four lower-
   order bits in the ID field.

So there is nothing very clear about what will happen if one will need
more than 15 HIT Suite-IDs... BTW according to appendix E I should add
"at the same time" (appendix E proposes to reuse values, making unlikely
to really need more than 15 values).

> For clarification, it might be a good idea to add some text that says 
> more explicitly that the OGA ID is formed by taking the four high-order 
> bits of the ID found in the HIT_SUITE_LIST, and by making the table read 
> something like:

=> it is trade-off between defining OGAs from HIT Suite-IDs vs.
defining HIT Suite-IDs from OGAs. The second was chosen...

> However, I wonder whether the better choice would be to simplify the 
> current encodings and make it a right-aligned field, keep the value 0 as 
> reserved, and leave future growth to future updates.  The same kind of 
> growth could be accommodated if the (future) extended OGA ID were 
> encoded with the nibbles swapped.

=> no, the current choice makes more sense with the HIT Suite-IDs
from OGAs. But it is a matter of taste for sure...

Regards

Francis Dupont <[e-mail]>