Subject: [Hipsec] 28 + 4 + 96 bit HIT crypto agility

From: Tobias Heer <[email-masked]>
Date: Tue, 02 Feb 2010 14:51:45 +0100

Hello, 

we have been discussing about different options to include the HIH (host identity hash) index in HIP packet or in the HIT. The most compelling option (at least to me and Bob) is encoding the HIH in the HIT directly. Advantages of this procedure are: 

a) No need to supply additional parameters with the HIT to convey the HIH.
This simplifies things like referrals and DNS (you just transfer an IPv6-comatible address instead of an address plus the HIH index).

b) A host can immediately determine if it can use a HIT.
There won't be any chance of receiving a HIT without knowing the type.

However, encoding the HIH in the HIT means that we have to sacrifice bits that could have been used for crypto / collision resistance.
The first question is how many bits we would have to sacrifice. I remember Tom asking if we could work with 4 bits for the HIH. I think one could work with four additional bits. This means that 16 different hash functions could be encoded at the same time. Of course we have to use crypto agility carefully then (i.e., we only introduce new HIH algorithms when the previous becomes insufficient). With 16 possible hash functions, this should give us plenty of time to completely phase out HIH #0 before #15 becomes insecure. If we look at the life-cycle of popular hash functions (MD5, SHA-1) 16 replacements represent a huge time frame. We could start over with #0 when #15 becomes insecure. 

Tom also asked whether 100 bits are enough or if we need more. From Julien's reply I take that it's not likely to get anything else than a /28 ORCHID prefix. So now the question is if fewer than 100 bits would do. Using 4 bits for crypto agility leaves us with 96 bits for the actual hash of the HI. Where will that put us in terms of collision resistance and security? I did some calculations based on the birthday paradox to give some examples and to get a feeling for the strength of 96 bits. However, I am not an expert on this, so please tell me if you have deeper insight into the required strength.

The following table gives the number of hashes you have to compute for a given output hash length until you reach a certain collision probability (CP). I put 128 bit there as a reference. 100 bit is the status quo with a 28 bit ORCHID prefix. 96 bit is with 28 bit ORCHID prefix and 4 bit HIH index.

  +---------+---------+---------+---------+---------+---------+       
  | Bits/CP | 0.5     | 0.25    | 0.01    | 0.001   | 0.0001  |       
  +---------+---------+---------+---------+---------+---------+       
  | 128 bit | 2.2E+19 | 1.4E+19 | 2.6E+18 | 8.3E+17 | 2.6E+17 |              
  | 100 bit | 1.3E+15 | 8.5E+14 | 1.6E+14 | 5.0E+13 | 1.6E+13 |       
  | 96 bit  | 3.3E+14 | 2.1E+14 | 4.0E+13 | 1.3E+13 | 4.0E+12 |       
  +---------+---------+---------+---------+---------+---------+ 

I pushed the collision probability down to 0.0001. For 96 bits you need a hash population of 4.0E+12 (4.000.000.000.000 / 4 trillion) to reach a collision with a probability of 0.0001.
100 bits will allow a population of 16 trillion before you reach the same probability.

Some closer-to-real-world-examples that Bob asked me to do take a given population (e.g., entries in an ACL). 
Given an ACL size of 10.000.000 (10 M) the chance of a collision is about 0,0000000000000007 (7E-16) for 96 bits.
Assuming an ACL of 680 billion (current world population x 100), the collision probability is 0,00000000000292 (2.92E-12) for 96 bits. For 100 bits the probability of a collision is 0,000000000000183 (1.83E-13)

These numbers are for benign collisions. For an attacker, it is important to compute a HIT (including public key) that matches another HIT. From the numbers above it seems to me that creating a collision for a determined HIT is out of scope. Creating any HIT collision (e.g. by creating a large number of HITs) will probably not be dangerous either, because the chance that the HIT for which you find the collision is in use is rather small (the address space will be very sparsely populated). What remains is to find a collision for a set of HITs (the HITs that are in use). I found some work on how to compute the probability for sets of random variables but I was unable to come up with useful results because of the very large (and very small) numbers involved. Even Scheme with its good math support was unable to handle the numbers. Maybe someone with matlab skills can help.

What I would like to know from the group: Do you think that a 28 + 4 + 96 bit HIT is a good choice? Do you think the cryptographic strength is sufficient? Do you have other preferences/alternatives?

BR, 

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 2 Feb 2010 08:35:37 -0800

Hi Tobias, thanks for continuing this thread.
>
> These numbers are for benign collisions. For an attacker, it
> is important to compute a HIT (including public key) that
> matches another HIT. From the numbers above it seems to me
> that creating a collision for a determined HIT is out of
> scope.

I think you mean "not practical" rather than "out of scope", right?  And by not practical, this means that the cost of mounting a second preimage attack by brute force (which includes the cost to create the key and hash it to test that it matches the target HIT) is likely to be 2^96 work for 96 bits if we continue to deprecate cracked hash functions over time, and that 2^96 (10^28) work is not likely to be feasible even for an attacker with large computing resources?

> Creating any HIT collision (e.g. by creating a large
> number of HITs) will probably not be dangerous either,
> because the chance that the HIT for which you find the
> collision is in use is rather small (the address space will
> be very sparsely populated). What remains is to find a
> collision for a set of HITs (the HITs that are in use). I
> found some work on how to compute the probability for sets of
> random variables but I was unable to come up with useful
> results because of the very large (and very small) numbers
> involved. Even Scheme with its good math support was unable
> to handle the numbers. Maybe someone with matlab skills can help.
>

Doesn't this question devolve into "if you are using N HITs, your attack surface to brute force attack goes up by a factor of N"?

> What I would like to know from the group: Do you think that a
> 28 + 4 + 96 bit HIT is a good choice? Do you think the
> cryptographic strength is sufficient? Do you have other
> preferences/alternatives?

Outside of the crypto issues, I think that encoding the HIH explicitly with some number of bits (your proposal seems adequate to me) is going to be preferable for ease of use considerations.

I think there are broader system and use case issues that would need to be considered in the analysis of whether 96 bits are enough.  For example, with 96 bits, might this mean that other vulnerabilities (lack of entropy in key generation, potential for users to mishandle keys) trump the brute force resistance?   Plus, it may be that we do not need to be bullet proof at this layer.  For an application that wants extra security, another independent security layer could be layered on top of HIP, rather than rely on HIP for channel bindings.  In such a case, attacks on HIP may just be of the DoS (packet redirection) variety, which again might be defused by robust system design and considering HIP to be a possible, albeit unlikely, point of failure.

By the way, can someone who was involved in the ORCHID deliberations chime in about the process for renewing the /28, and what are the issues to make this a permanent allocation?

Tom

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 2 Feb 2010 10:42:45 -0800

Hello Tom,

Henderson, Thomas R wrote:
> [...]
> 
> By the way, can someone who was involved in the ORCHID deliberations
> chime in about the process for renewing the /28, and what are the
> issues to make this a permanent allocation?

The current assignment for ORCHID terminates on 21 Mar 2014. The registration procedure for the IANA IPv6 Special Purpose Address Registry is IETF Consensus, see:

 http://www.iana.org/assignments/iana-ipv6-special-registry/

Since we're now discussing a HIT/ORCHID design that differs from the one originally documented in RFC 4843, updating RFC 4843 could 1) update the ORCHID design with hash agility, and 2) establish IETF consensus for a never ending ORCHID assignment in the relevant IANA registry.

--julien

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 02 Feb 2010 14:30:22 -0500

On 02/02/2010 11:35 AM, Henderson, Thomas R wrote:
> I think there are broader system and use case issues that would need to be considered in the analysis of whether 96 bits are enough.  For example, with 96 bits, might this mean that other vulnerabilities (lack of entropy in key generation, potential for users to mishandle keys) trump the brute force resistance?

How is the size of the truncation of the hash of the HI of any import to 
the strength of the key obtained? They seem to be orthogonal to me.

>     Plus, it may be that we do not need to be bullet proof at this layer.  For an application that wants extra security, another independent security layer could be layered on top of HIP, rather than rely on HIP for channel bindings.  In such a case, attacks on HIP may just be of the DoS (packet redirection) variety, which again might be defused by robust system design and considering HIP to be a possible, albeit unlikely, point of failure.
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 2 Feb 2010 12:14:22 -0800

> > I think there are broader system and use case issues that
> would need to be considered in the analysis of whether 96
> bits are enough.  For example, with 96 bits, might this mean
> that other vulnerabilities (lack of entropy in key
> generation, potential for users to mishandle keys) trump the
> brute force resistance?
>

I don't think it is related.  My point was that we ought to have the big picture security threat analysis in mind when we make a decision about how much security is enough for one aspect of the overall design.

I recall that you said once that the point of HIP security was to prevent the network layer mechanisms (packet forwarding and redirection) from being attacked (apologies if I misquote you or remember this imperfectly).  Is making the attacker do 96 bits worth of work just so he/she can disrupt network layer mechanisms enough in this case?  If however, the user stakes all end-to-end security on HIP (i.e. channel bindings), then maybe the stakes are higher.

Tom

---

From: Miika Komu <[email-masked]>
Date: Wed, 03 Feb 2010 12:39:17 +0200

On 02/02/2010 06:35 PM, Henderson, Thomas R wrote:

Hi,

>> What I would like to know from the group: Do you think that a 28 +
>> 4 + 96 bit HIT is a good choice? Do you think the cryptographic
>> strength is sufficient? Do you have other

I believe the 28 + 4 + 96 scheme is a good idea, assuming that we really
won't get a larger prefix from IANA. However, I have a question on the 
four bits that perhaps needs to be asked aloud even though the answer is
probably "no". Currently, the four bits for the algo are just "hints",
i.e., they are not securely bound to the HIT calculation. Should they be
included in the HIT calculation?

> Outside of the crypto issues, I think that encoding the HIH
> explicitly with some number of bits (your proposal seems adequate to
> me) is going to be preferable for ease of use considerations.
>
> I think there are broader system and use case issues that would need
> to be considered in the analysis of whether 96 bits are enough.  For
> example, with 96 bits, might this mean that other vulnerabilities
> (lack of entropy in key generation, potential for users to mishandle
> keys) trump the brute force resistance?   Plus, it may be that we do
> not need to be bullet proof at this layer.  For an application that
> wants extra security, another independent security layer could be
> layered on top of HIP, rather than rely on HIP for channel bindings.
> In such a case, attacks on HIP may just be of the DoS (packet
> redirection) variety, which again might be defused by robust system
> design and considering HIP to be a possible, albeit unlikely, point
> of failure.

I think it would be useful to add some text on this e.g. in RFC5201-bis.

---

From: Tobias Heer <[email-masked]>
Date: Wed, 03 Feb 2010 13:56:03 +0100

Hello Tom.

> I think you mean "not practical" rather than "out of scope", right?  And by not practical, this means that the cost of mounting a second preimage attack by brute force (which includes the cost to c…

Right. Yes, that's the assumption. Moreover, finding a second preimage only is not enough. The second preimage needs to be a public key that the attacker has to generate. Right now, generating an asymmetric key pair causes considerable overhead (at least for RSA and DSA). However, I can imagine that we might encounter public-key schemes for which key generation is relatively cheap, so I would not like to base the security of the scheme on the assumption that key generation is expensive. 

>From what I have read [3], its not that easy. It's a tough combinatorial problem... but I may have misunderstood it. The problem is to compute the collision probability of two sets of random values. Both sets are of different size. The first set is the set of HITs in use, the second set is the set of HIs and HITs that an attacker generates in order to find a collision. 

> I think there are broader system and use case issues that would need to be considered in the analysis of whether 96 bits are enough.  For example, with 96 bits, might this mean that other vulnerabi…

You are right here. I guess an important question is also if the HIT is easier to crack than the HI itself. An example: when using a 1024 bit RSA HI, its strength is routhly equivalent to a 80-bit symmetric cipher [1]. This might be easier to crack than the 96 bit in the HIT. I am not sure if the bit lengths can be compared directly but *iff* this is the case, 96 bits would be somewhere between RSA with 1553 and 1926 bit keys[2]. 100 bits is equivalent to RSA 1926. Iff this assumption holds, 96 bit HITs would only be a weak spot for RSA keys above that length.

>  Plus, it may be that we do not need to be bullet proof at this layer.  For an application that wants extra security, another independent security layer could be layered on top of HIP, rather than…

Another option would be to put more emphasis on the HI itself. Even if the application only sees the HI, the HIP stack will see the HI itself. By managing lists of known identities (just like SSH does), the HIP layer could figure out that a collision occurred (and issue a warning or deny the communication). However, this will only help if the peer has had the chance to see both hits.

If we neglect accidental (benign) collisions, one could also considering methods to make HIT or HI generation more costly in terms of computations. Such artificial hardening (similar to what CGA does) could be adjusted over time to compensate advances in cryptography and Moore's law. I guess we can come up with a sensible method if this is the desired direction for HIP.

Tobias

References:
[1] http://www.rsa.com/rsalabs/node.asp?id=2088
[2] RFC 3766
[3] Michael C. Wendl, Collision probability between sets of random variables, Statistics & Probability Letters, Volume 64, Issue 3, 15 September 2003, Pages 249-254

--

---

From: Tobias Heer <[email-masked]>
Date: Wed, 03 Feb 2010 15:29:30 +0100

Hello Miika, 

Am 03.02.2010 um 11:39 schrieb Miika Komu:

> won't get a larger prefix from IANA. However, I have a question on the four bits that perhaps needs to be asked aloud even though the answer is

Since the HIH bits are a pointer to a specific hash function and that specific hash function was used to generate the HI hash bits the binding is already there. Changing the HIH bits would cause the HIT verification to fail. Hence, IMHO, tampering with these bits is rather ineffective.

However, thanks for asking the question anyway.

Tobias

--

---

From: Tobias Heer <[email-masked]>
Date: Thu, 04 Feb 2010 15:47:11 +0100

Hello Pekka,

On 02.02.2010, at 15:02, Pekka Nikander wrote:

> Tobias and Bob,
> 
> I think you should talk to Sam Hartman about how Orchids were designed.  Initially Orchids had the same feature: a few bits reserved to denote the crypto algorithm.  But then Sam (IIRC) came with the present Orchid way, where those bits are not needed.  I don't remember the details and rationale any more, and since I'm not working with HIP anymore, I wouldn't have the time to check.

Thanks for the reply. RFC 4843 is quite clear why these bits are not needed. ORCHIDs don't offer support for multiple hash functions within one context ID. Different hash functions require different context IDs. In addition, the context ID is not encoded in the ORCHID directly because of the underlying assumption that the application will know its context ID. This works fine as long as every application uses only few different context IDs (as long as trying out which context id matches is sufficient). However, this assumes that the context ID and the preimage of the hash are known. This is not the case for the current attempts to add crypto agility for HIT. Hence, adding crypto agility to ORCHIDs in the way we are currently discussing it would probably lead to a redesign of the ORCHID.

RFC 4942 is also quite clear that future versions of the ORCHID work should think about hash extension mechanisms (like in CGA). This might be a way out of the 96 vs 100 bit trap.

Tobias
   
[removed trailing text]

--

---

From: Tobias Heer <[email-masked]>
Date: Wed, 24 Feb 2010 12:33:30 +0100

Hello Julien, Tom, and everyone else on the list, 

since the HIH/HIT/ORCHID discussion died, I'd like to revive it to come to a conclusion. I'll sum up some of the previous mails to make the information a bit more accessible.

[...]

> Since we're now discussing a HIT/ORCHID design that differs from the one originally documented in RFC 4843, updating RFC 4843 could 1) update the ORCHID design with hash agility, and 2) establish I…

I am still in favor of changing the ORCHID format to support hash agility instead of transmitting auxiliary information in the HIP headers or HIP parameters. Advantages are:

a) You'll never get a HIT for which you can't tell which algorithm was used (even if the auxiliary information is missing). This makes it more usable for referrals and legacy applications (also for non-legacy applications that still use the (legacy) socket interface) because these can continue to handle HITs like IPv6 addresses without special treatment.
b) It's far less complex than having an additional parameter in HIP for which you need rules when to transmit it (packet types) and where to put it (parameter number).
c) It's slightly more space efficient than having another field in the HIP header since there isn't terribly much space left in the header. Just adding 4 or 8 bits to the header would screw the alignment. Hence, even more bits would be needed as padding. There are 3 reserved bits but I guess one should try to keep them for future use - I think right now we are agile enough to actually make changes that break compatibility with older versions.

The main disadvantages are:
a) We'd have to change the way ORCHIDs are created because RFC 4843 is quite strict on the procedure.
b) We'd sacrifice some bits and would weaken the HIT against attacks.

Disadvantage b) can be mitigated by using a hash extension mechanism similar to the one in CGA (artificially making HIT generation more CPU intensive). RFC 4843 explicitly states that such mechanism should be considered for future versions of the ORCHID, so I guess there is no fundamental problem here. The only issue might be the IPR questions that were open at the time RFC 4843 was written (it was published in April 2007). I don't have any insight into this but I can investigate if people feel that this is the way to go.

I would like to ask for the opinion of the group regarding the redefinition/extension of the way ORCHIDS are created. Should this be done or should we try to live with one of the workarounds in order to add crypto agility to the HIT.

What would be the right procedure to get this going? Write a draft? If yes: who should/would do it?

BR, 

Tobias

--

---

From: Miika Komu <[email-masked]>
Date: Wed, 24 Feb 2010 17:33:09 +0200

On 24/02/10 13:33, Tobias Heer wrote:

Hi,

> I would like to ask for the opinion of the group regarding the
> redefinition/extension of the way ORCHIDS are created. Should this be
> done or should we try to live with one of the workarounds in order to
> add crypto agility to the HIT.

I am still in favor of some extra bits for the algorithm. Let's do it 
right and no workarounds please.

> If yes: who should/would do it?

Shouldn't this go to RFC5201-bis?

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 24 Feb 2010 08:34:32 -0800

> right and no workarounds please.

I concur.

I am not very concerned about incompatibilities outlined by Tobias: we can let the current temporary prefix allocation for ORCHID expire (in 2014) and request permanent allocation of another prefix for ORCHIDv2. That should be enough to handle the transition period.

> Shouldn't this go to RFC5201-bis?

Hmm...

During the discussion that led to the allocation of a special purpose IPv6 prefix for ORCHIDs, a major concern was that this could open the pandora box of having every organization request an IPv6 prefix to number their favorite things, e.g., cellular phones, vehicles, <insert your favorite thing here>.

One of the reason we were successful in getting an IPv6 prefix special allocation for ORCHIDs is because ORCHIDs are generic IPv6-adddress-formatted cryptographic identifier, and not just HITs, specific to one protocol, HIP.

So I think we should stick to that as it has worked well for us in the past, and thus keep ORCHID definition in a standalone document. Revising 4843 looks reasonably easy. I can work on an update if we can agree on a high level design.

Would there be consensus to update ORCHIDs to v2 as follows:

- ORCHIDv2 structured as 28 + 4 + 96 bits
- 28 bits are new prefix for ORCHIDv2
- 4 bits encodes hash
- 96 bits are hashed string

Note that CGA's hash extension techniques (with Sec parameter) have been updated with some hash agility support in [RFC4982]; do we want to do something similar? Or do we want to use standalone hash extension in the 96 bits, as in the original CGA design [RFC3972]?

--julien

[RFC3972] tools.ietf.org/html/rfc3972
[RFC4982] tools.ietf.org/html/rfc4982

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 24 Feb 2010 10:57:01 -0800

> > right and no workarounds please.

+1

> Note that CGA's hash extension techniques (with Sec
> parameter) have been updated with some hash agility support
> in [RFC4982]; do we want to do something similar? Or do we
> want to use standalone hash extension in the 96 bits, as in
> the original CGA design [RFC3972]?
>

I support the above.  Regarding your question, I would recommend that we say for now that "4 bits encodes the hash string generation algorithm" because it may not simply be a hash algorithm but something like hash extension of CGA.

Note that if we make ORCHIDs generic, the 4 bits must be shared among all the possible users in the future.  I don't think it is a big concern because the current use outside of HIP seems to be limited.

It would be nice to discuss and then state in one of the drafts (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for the following:
- future allocations of new ORCHID prefixes?  Are there any conditions that would lead to asking for additional ORCHID prefixes, or do we expect only one such prefix?
- what happens if the four bits runs out (do we deprecate old values such as in RFC4982?)
- some discussion of the relationship between HITs, LSIs, ORCHIDs, and other quantities.
  ** future extension of HIT size (256 bits has been raised in the past)-- is this possible or are we closing the door on such a future extension?.  More generally, does HIP allow for HITs that are not ORCHIDs?  (e.g. the old type-2 HITs, or more recent proposals for hierarchical HITs)  Do we use the bits in the HIP control field to identify HIT type?
  ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari have floated this idea in the past)
  ** LSI prefix for IPv4  (recall we discussed a /16 in the 127/8 space-- do we also want to resolve this issue while we are resolving ORCHIDs?)
  ** are LSIs possible for IPv6?  When would they be used instead of ORCHIDs?

Tom

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 24 Feb 2010 14:23:48 -0800

> > > right and no workarounds please.

+1 here too. The HIT with algorithm bits will make life much easier.

-Jeff

---

From: Tobias Heer <[email-masked]>
Date: Fri, 26 Feb 2010 14:19:26 +0100

Hi Tom, 

Am 24.02.2010 um 19:57 schrieb Henderson, Thomas R:
[...]

> I support the above.  Regarding your question, I would recommend that we say for now that "4 bits encodes the hash string generation algorithm" because it may not simply be a hash algorithm but som…
You got a very good point here. I agree.

> Note that if we make ORCHIDs generic, the 4 bits must be shared among all the possible users in the future.  I don't think it is a big concern because the current use outside of HIP seems to be lim…

I don't think that is a big concern. The ORCHID is designed in a way that the context ID is not visible from the ORCHID. Hence, all protocols that use ORCHIDS need checks whether a given ORCHID actually matches the current protocol context. As far as I can tell, this is done by simple trial and error: hash the public key and the context ID and see if it matches. Now, with the 4 additional bits, for a new (4+96 bit) ORCHID, the protocols that use the old ORCHID format check for the context ID again and the test would fail. In that case, the protocol would figure that it is an ORCHID of another protocol - no harm done... and no need to "share" the four bits. Am I missing something here?

> It would be nice to discuss and then state in one of the drafts (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for the following:

I tried to distribute your (good) questions to the three documents. I took the liberty to number the questions below.
I think question 3 would fit into 4843-bis nicely. There is already a short part on HITs and LSIs. One could easily extend this to go into ORCHIDS a bit more.
RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I think that it should stay like that. Your questions 1 and 2 would be good here.
Do you want to discuss the answers to your questions on the list or are these meant as todo for the authors of the respective documents.

I can adjust the text in RFC5201-bis to match the new HIT format and the resulting changes in the BEX. Part of it was already done together with Bob anyway. I will post the result on the list. 

1.)
> - future allocations of new ORCHID prefixes?  Are there any conditions that would lead to asking for additional ORCHID prefixes, or do we expect only one such prefix?
2.)
> - what happens if the four bits runs out (do we deprecate old values such as in RFC4982?)
3.)

Tobias

--

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 26 Feb 2010 08:06:46 -0800

Tobias,

Did you swapped 4423 and 4843 in your note below? I'd expect non-HIP-specific 1 & 2 to be discussed in 4843bis / ORCHIDv2, while HIP-specific 3 clearly belongs to 3.

--julien

Tobias Heer wrote:
> > I support the above.  Regarding your question, I would recommend that
> we say for now that "4 bits encodes the hash string generation
> algorithm" because it may not simply be a hash algorithm but something
> like hash extension of CGA.
> >
> > Note that if we make ORCHIDs generic, the 4 bits must be shared among
> all the possible users in the future.  I don't think it is a big
> concern because the current use outside of HIP seems to be limited.
> >
> 
> I don't think that is a big concern. The ORCHID is designed in a way
> that the context ID is not visible from the ORCHID. Hence, all
> protocols that use ORCHIDS need checks whether a given ORCHID actually
> matches the current protocol context. As far as I can tell, this is
> done by simple trial and error: hash the public key and the context ID
> and see if it matches. Now, with the 4 additional bits, for a new (4+96
> bit) ORCHID, the protocols that use the old ORCHID format check for the
> context ID again and the test would fail. In that case, the protocol
> would figure that it is an ORCHID of another protocol - no harm done...
> and no need to "share" the four bits. Am I missing something here?
> 
> 
> > It would be nice to discuss and then state in one of the drafts
> (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for
> the following:
> 
> 
> I tried to distribute your (good) questions to the three documents. I
> took the liberty to number the questions below.
> I think question 3 would fit into 4843-bis nicely. There is already a
> short part on HITs and LSIs. One could easily extend this to go into
> ORCHIDS a bit more.
> RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I
> think that it should stay like that. Your questions 1 and 2 would be
> good here.
> Do you want to discuss the answers to your questions on the list or are
> these meant as todo for the authors of the respective documents.
> 
> I can adjust the text in RFC5201-bis to match the new HIT format and
> the resulting changes in the BEX. Part of it was already done together
> with Bob anyway. I will post the result on the list.
> 
> 
> 1.)
> > - future allocations of new ORCHID prefixes?  Are there any
> conditions that would lead to asking for additional ORCHID prefixes, or
> do we expect only one such prefix?
> 2.)
> >  ** future extension of HIT size (256 bits has been raised in the
> past)-- is this possible or are we closing the door on such a future
> extension?.  More generally, does HIP allow for HITs that are not
> ORCHIDs?  (e.g. the old type-2 HITs, or more recent proposals for
> hierarchical HITs)  Do we use the bits in the HIP control field to
> identify HIT type?
> >  ** LSI prefix for IPv4  (recall we discussed a /16 in the 127/8
> space-- do we also want to resolve this issue while we are resolving
> ORCHIDs?)

---

From: Tobias Heer <[email-masked]>
Date: Fri, 26 Feb 2010 18:27:03 +0100

Hi Julien, 

> Did you swapped 4423 and 4843 in your note below? I'd expect non-HIP-specific 1 & 2 to be discussed in 4843bis / ORCHIDv2, while HIP-specific 3 clearly belongs to 3.

you are absolutely right. I mixed the numbers in my reply. Sorry for causing confusion.

Tobias

--

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 26 Feb 2010 09:32:12 -0800

> -----Original Message-----
> From: Tobias Heer [mailto:[email-masked]]
> Sent: Friday, February 26, 2010 5:19 AM
> To: Henderson, Thomas R
> Cc: 'Laganier, Julien'; [email-masked]; [email-masked]
> Subject: Re: [Hipsec] ORCHID IANA allocation
>
<snip>
>
> I don't think that is a big concern. The ORCHID is designed
> in a way that the context ID is not visible from the ORCHID.
> Hence, all protocols that use ORCHIDS need checks whether a
> given ORCHID actually matches the current protocol context.
> As far as I can tell, this is done by simple trial and error:
> hash the public key and the context ID and see if it matches.
> Now, with the 4 additional bits, for a new (4+96 bit) ORCHID,
> the protocols that use the old ORCHID format check for the
> context ID again and the test would fail. In that case, the
> protocol would figure that it is an ORCHID of another
> protocol - no harm done... and no need to "share" the four
> bits. Am I missing something here?

I think you are right.

> Do you want to discuss the answers to your questions on the
> list or are these meant as todo for the authors of the
> respective documents.

I think we should discuss them on the list.  For questions 1 and 2, I do not care so much about the answer, other than we just document what future plans are envisioned.  Question 3 is more interesting and we are already discussing with the RELOAD draft.

- Tom

>
> I can adjust the text in RFC5201-bis to match the new HIT
> format and the resulting changes in the BEX. Part of it was
> already done together with Bob anyway. I will post the result
> on the list.
>
>
> 1.)
> conditions that would lead to asking for additional ORCHID
> prefixes, or do we expect only one such prefix?
> 2.)
> >  ** future extension of HIT size (256 bits has been raised
> in the past)-- is this possible or are we closing the door on
> such a future extension?.  More generally, does HIP allow for
> HITs that are not ORCHIDs?  (e.g. the old type-2 HITs, or
> more recent proposals for hierarchical HITs)  Do we use the
> bits in the HIP control field to identify HIT type?
> >  ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo
> and Jari have floated this idea in the past)
> >  ** LSI prefix for IPv4  (recall we discussed a /16 in the
> 127/8 space-- do we also want to resolve this issue while we
> are resolving ORCHIDs?)