Hi Tom, FWIW your proposal looks good to me.
--julien On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson <[email protected]> wrote: > 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 > > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
