On 09/29/2014 09:20 AM, [email protected] 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 <[email protected]>
An: Tom Henderson <[email protected]>,
Kopie: HIP <[email protected]>, Francis Dupont <[email protected]>,
[email protected]
Datum: 26.09.2014 12:39
Betreff: Re: [Hipsec] clarification on HIT Suite IDs
Gesendet von: "Hipsec" <[email protected]>
------------------------------------------------------------------------
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
