On 09/29/2014 09:20 AM, Tobias.Heer@Belden.com wrote:
> Hello,
>
> I'd like to confirm some of your statements. The thought was really to
> show both options a) reuse of OGAs and b) what could happen if we need
> more bits. However, the wording and the current set of IDs was chosen so
> that it discourages the use of more IDs at the same time so the option
> to take more bits from the OGA was really just a last resort. Nothing
> anybody would really want.
>
> See my comments below.
>
>
>
>
> Von: Francis Dupont <fdupont@isc.org>
> An: Tom Henderson <tomh@tomh.org>,
> Kopie: HIP <hipsec@ietf.org>, Francis Dupont <fdupont@isc.org>,
> julien.ietf@gmail.com
> Datum: 26.09.2014 12:39
> Betreff: Re: [Hipsec] clarification on HIT Suite IDs
> Gesendet von: "Hipsec" <hipsec-bounces@ietf.org>
> ------------------------------------------------------------------------
>
>
>
> Tom Henderson writes:
>  >        For the time being, the HIT Suite uses only four bits because
>  >        these bits have to be carried in the HIT.  Using more bits for the
>  >        HIT Suite ID reduces the cryptographic strength of the HIT.
>
> => yes, there is a long discussion in RFC 7343 about this tradeoff.
>
>  > which implied to me that the HIT suite ID may in the future consume more
>  > bits presently allocated to hash.
>
> => the fact the problem could exist doesn't mean it will exist...
>
> TH=> This was just to cover all options. It is not a desired or intended
> action.

There is discussion of this in the IANA considerations section; perhaps 
this could be modified as follows:

Old text:

       If 16 Suite IDs prove insufficient and
       more HIT Suite IDs are needed concurrently, more bits can be used
       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
       that more bits should be used.  The HIT_SUITE_LIST parameter
       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
       Possible extensions of the HIT Suite ID space to accommodate eight
       bits and new HIT Suite IDs are defined through IETF Review.

New text:

       If 15 Suite IDs (the zero value is initially reserved) prove
       to be insufficient and
       more HIT Suite IDs are needed concurrently, more bits can be used
       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
       that more bits should be used.  The HIT_SUITE_LIST parameter
       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
       However, RFC 7343 does not presently support such an extension,
       and the rollover approach described in Appendix E is suggested to
       be tried first.
       Possible extensions of the HIT Suite ID space to accommodate eight
       bits and new HIT Suite IDs are defined through IETF Review.



>
>  > > 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).
>  >
>  > I'm not sure where you are proposing to add the clause; can you point
>  > out the sentence?
>
> => one will need more than 15 HIT Suite-IDs ->
> one will need more than 15 HIT Suite-IDs at the same time
>
> TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are
> reasonably out of use. Appendix E describes this rollover.

So for this proposal by Francis, we would change Appendix E text from:

    Since
    the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID
    0 is reserved) to be used in parallel, phased-out HIT Suites must be
    reused at some point.  In such a case, there will be a rollover of

to:

    Since
    the 4-bit OGA field only permits 15 HIT Suites to be used at the
    same time (the HIT Suite with ID 0 is reserved), phased-out HIT
    Suites must be
    reused at some point.  In such a case, there will be a rollover of

>
>  > > => no, the current choice makes more sense with the HIT Suite-IDs
>  > > from OGAs. But it is a matter of taste for sure...
>  >
>  > Perhaps we could start by trying to resolve whether the plan should be
>  > to reuse four-bit values if the space is eventually exceeded, or whether
>  > the HIT suite ID may grow in the future (and how that affects the
>  > ORCHID).
>
> => clearly the current plan is the first (reuse 4 bit values).
> The second is just a provision in the case the first fails.
>
> TH=> Yes. I can confirm this.
>
>  > Maybe we do not need to specify the plan in this draft; maybe
>  > we could just avoid the problem for now and just keep value 0 reserved
>  > and state that what to do when the HIT_SUITE_ID space is exhausted is
>  > for further study, with deprecated value reuse and expansion of the HIT
>  > Suite ID being two possibilities.
>
> => perhaps it was considered as too optimistic? BTW I have no idea
> about the future need in new values in the HIT_SUITE_ID / OGA space
> (but does somebody already have one?)
>
> TH=> I am fine with not specifying the extension of the ID but to leave
> 0 as reserved instead.

Julien suggested that if we consider non-zero bits as an error at the 
receiver, it may facilitate use of the four non-zero high-order bits in 
future extensions.

in 5.2.10, it says:

                     The four
                     lower-order bits are reserved and set to 0 and
                     ignored by the receiver.

The proposal would be to change this to:

                     The four
                     lower-order bits are reserved and set to 0 by
                     the sender.   The reception of an ID with
                     the four lower-order bits not set to 0 should be
                     considered as an error that MAY result in a
                     NOTIFICATION of type UNSUPPORTED_HIT_SUITE.

Any comments/concerns with this potential change?

>
>  > Another basic question I have is whether the table 11 in Appendix E
>  > should be merged with the unlabeled table at the end of 5.2.10 (and
>  > located in 5.2.10), and whether Appendix E text in general ought to be
>  > brought forward in the draft to section 3.2 and/or 5.2.10.
>
> => it is a question for the hipsec mailing list (I subscribed to it
> but from my personal e-mail).
>
> TH=> Moving the table to 5.2.10 is fine from my perspective.

I tend to prefer this; I will work up a proposal for this.

- Tom