Re: [Hipsec] Antwort: Re: clarification on HIT Suite IDs

[Miika Komu <[e-mail]>]

Hi,

seems ok to me too.

On 09/29/2014 08:53 PM, Julien Laganier wrote:
> Hi Tom,
>
> FWIW your proposal looks good to me.
>
> --julien
>
> On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson <[e-mail]> wrote:
>> On 09/29/2014 09:20 AM, [e-mail] 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 <[e-mail]>
>>> An: Tom Henderson <[e-mail]>,
>>> Kopie: HIP <[e-mail]>, Francis Dupont <[e-mail]>,
>>> [e-mail]
>>> Datum: 26.09.2014 12:39
>>> Betreff: Re: [Hipsec] clarification on HIT Suite IDs
>>> Gesendet von: "Hipsec" <[e-mail]>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> 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
>>
>>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>