Subject: [Hipsec] Is a HIT 126 or 128 bits long?

From: [email-masked] (Julien Laganier)
Date: Wed Oct 13 09:14:00 2004

Folks,

In a private conversation (excerpt included at the end of the mail), 
Pekka and I talked about making HITs stored in the DNS type-opaque 
(the HIT doesn't contains bits telling its type), i.e.:

Type1_HIT = SHA1_128(HI)
Type2_HIT = HAA_64 + SHA1_64(HI)

While the HIP base spec currently specifies that HITs used in the base 
protocol are of the form:

Type1_HIT = 01 + SHA1_126(HI)
Type2_HIT = 10 + HAA_62 + SHA1_64(HI)

So at this point, I'd like to know what the WG consensus is w.r.t. the 
following questions:

o Should we store 128 and 64+64 bits HITs in the DNS?
o Should we use 128 and 64+64 bits HITs in the HIP header?
o Should we derive and use 127 and 63+64 bits HITs in the legacy 
IPv6-compatible API for IPv6 apps? (This would be similar to the 
HIP-internal NATing that some people evocate about LSIs, or IP 
addresses as AIDs)
o Should we think now to use longer HITs (e.g. using SHA256) in the 
protocol and the DNS?

Thanks,

--julien

Pekka Nikander wrote:
>
>Julien Laganier wrote:
> > 
> >Pekka Nikander wrote:
> >> If we remove the HIT vs IPv6 LSI discussion from earlier on,
> >> we have to change 5.1.3.  My suggestion is that we store the
> >> full 128 bit hash into the Type 1 HIT field, and define the
> >> Type 2 and HAA fields to have 64 bits of HAA, where the HAA
> >> includes the prefix (if any).
> >
> > If I understand correctly, that means that HITs would be
> > type-opaque, right? Is this not a problem if one wants to perform
> > HIT-based access control? Also, how does a node verify its peer's
> > HIT with the current protocol (the exchange doesn't include the
> > peers' HIT type) ?
>
> Remember that we are defining only DNS use, not how HITs are used,
> e.g., in the base spec.  We can use 128-bit hashes in the DNS,
> as the RR explicitly lists the HIT type, and then use only 126-bit
> hashes in the base exchange.  Maybe add:
>
>    Note that the format how HITs are stored in the DNS may be
>    different form the format actually used in protocols, the
>    HIP base exchange <ref> included.  This is because the DNS
>    RR explicitly contains the HIT type, while some protocols
>    may prefer to use a prefix to indicate the HIT type.  The
>    implementations are expected to use the actual HI when
>    comparing Host Identities.
>
> >> But this seems to be something that we probably have to discuss
> >> at the WG.
> >
> > Should I send an email to the ML?
>
> Yes.  I think the suggestion is that
>
>   - use 128 or 64+64 bit HITs in the DNS
>   - continue using 2+126 and 2+62+64 bit HITs in the
>     base specification, for now
>   - be open to even longer HITs, e.g. 256-bit long

-- 
Julien Laganier 
SUN Microsystems Laboratories

---

From: [email-masked] (Tim Shepard)
Date: Wed Oct 13 09:44:01 2004

> o Should we think now to use longer HITs (e.g. using SHA256) in the 

I don't know if we want to change the base spec at this particular
point in time, but I believe a deployable HIP will need to support
longer HITs.

There was also an understanding (in hallway conversations at IETF
meetings) that the LSI's passed accross IPv6 APIs would be a few to a
dozen bits shorter than 128 bits (with a constant prefix prepended to
fill 128 bits), so as not to consume too much of the IPv6 address
space with this hack to allow references to HITs to be passed where
APIs already support IPv6 addresses.  The kernel could maintain a
table maping these LSIs to the acutal HITs, whatever there lenght may
be, and would presumably use the bottom 120 or so bits of the HIT as
the bottom bits of the LSI.  (Collisions would be unlikely.)

At least that's my memory of this issue.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Julien Laganier)
Date: Wed Oct 13 10:45:01 2004

On Wednesday 13 October 2004 16:52, Tim Shepard wrote:
> > o Should we think now to use longer HITs (e.g. using SHA256) in
> > the protocol and the DNS?
>

I agree that changing the base spec at this point might be problematic 
(especially because HITs are in the base header which is supposed to 
have a fixed length).

I think, however, that we can easily introduce variable length data 
structure to store HIT in the DNS, which might be useful in the 
future.

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 14 05:06:01 2004

> point in time, but I believe a deployable HIP will need to support

I concur.

> At least that's my memory of this issue.

Your memory matches closely with mine.  IIRC, we also felt that for
practical purposes, we could continue with the HIT prefixes for then,
and review the issue when we get close to publication.  Maybe we are
now closer to publication.

If the WG feels so, I would suggest the following changes to the base
and DNS specs:

1. Change the common header to include HIT types in Control:

    The following fields have been defined:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SHT | DHT | | | | | | | | |C|A|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    SHT   Sender's HIT Type.  Currently the following values are
          specified:

           0 RESERVED
           1 Type 1 HIT
           2 Type 2 HIT
         3-6 UNASSIGNED
           7 RESERVED

    DHT  Destionation's HIT type.

2. Change the DNS draft so that HAA has the HIT type of 7:

    5.1.1  RDATA format HIT type

       ....

       2 A 128-bit Type 2 HIT is present.
       7 A 128-bit HAA is present.

    The idea is that there is only one IANA registry for the values
    1-6, and values 0 and 7 are reserved in the IANA registry.

3. Change the text so that Type 1 HITs don't have any prefix at all,
    Type 2 HITs have a prefix TBD of length TBD.  (To be assigned by 
IANA)

>    There are two types of HITs.  HITs of the first type, called *type 1
>    HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits
            consist of 128 bits
>    of the SHA-1 hash of the public key.  HITs of the second type 
> consist
>    of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA)
                   TBD-bit prefix of TBD,
>    field, and only the last 64 bits come from a SHA-1 hash of the Host
>    Identity. This latter format for HIT is recommended for 'well known'
>    systems.  It is possible to support a resolution mechanism for these
>    names in hierarchical directories, like the DNS. Another use of HAA
>    is in policy controls, see Section 12.

Add:

     As the type of a HIT cannot be determined by inspecting its 
contents,
     the HIT type must be communicated by some external means.

     Historically, some early implementations had a 2-bit prefix of 01
     for Type 1 HITs.  It is expected to be a common practice to use
     that or a similar but longer prefix at the legacy IPv6 API; see
     Appendix A.  Consequently, it is RECOMMENDED that implementations
     ignore the left most TBD bits when comparing HITs for equality.

4. Add some text about IPv6 LSIs to Appendix A

     (I think the -00 version of the DNS draft has text that might
      fit in there, at least if slightly edited.)

Opinions?

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Thu Oct 14 08:22:01 2004

Hi Pekka,

I basically agree with the changes you are proposing. I modified the 
IPv6 LSI text of the -00 of the DNS draft, included below,

On Thursday 14 October 2004 12:13, Pekka Nikander wrote:
> If the WG feels so, I would suggest the following changes to the
> base and DNS specs:
>
> 3. Change the text so that Type 1 HITs don't have any prefix at
> all, Type 2 HITs have a prefix TBD of length TBD.  (To be assigned
> by IANA)
>
> >    There are two types of HITs.  HITs of the first type, called
> > *type 1 HIT*, consist of an initial 2 bit prefix of 01, followed
> > by 126 bits
>
>             consist of 128 bits
>
> >    field, and only the last 64 bits come from a SHA-1 hash of the
> > Host Identity. This latter format for HIT is recommended for
> > 'well known' systems.  It is possible to support a resolution
> > mechanism for these names in hierarchical directories, like the
> > DNS. Another use of HAA is in policy controls, see Section 12.
>
> Add:
>
>      Historically, some early implementations had a 2-bit prefix of
> 01 for Type 1 HITs.  It is expected to be a common practice to use

=> Here's a modified excerpt matching the modifications you proposed:

The first bit of a HIT is used to differentiate between Type 1 and
Type 2 format. If the first bit is 0 then the rest of a HIT is the
127 upper bits of a SHA-1 hash of the Host Identity. If the first bit
is 1 then the next 63 bits is the HAA field, and only the last 64
bits come from the hash of the Host Identity.

Additionnaly, this document defines an internal IPv6-compatible LSI
representation format, to be used within the legacy IPv6-compatible
API (e.g., socket over AF_INET6). The format of these IPv6-compatible
LSIs is designed to avoid the most commonly occurring IPv6 addresses
in RFC3596 [9]. An IPv6-compatible LSI representation is easily
computed by replacing the first TBDth bits of the corresponding HIT by 
the TBD bits long prefix "0xTBD". 

      Allocation                   Prefix          Fraction of IPv6
                                   (binary)        Address Space
      ------------------------     --------        -------------

      IPv6 Address space           00              1/4
      IPv6-compatible LSI          TBD             1/2^TBD
      IPv6 Address space           11              1/4

=> Question: Do we need to include the type of the HIT in one of the 
IPv6 LSI bits? If so, replace the last sentence and the table of the 
text above by:

An IPv6-compatible LSI representation is easily
computed by replacing the first TBDth bits of the corresponding HIT by 
the TBD-2 bits long prefix "0xTBD", while TBD-1th and TBDth bits are 
set to 01 for a Type 1 HIT, and 10 for a Type2 HIT

      Allocation                   Prefix          Fraction of IPv6
                                   (binary)        Address Space
      ------------------------     --------        -------------

      IPv6 Address space           00              1/4
      Type 1 IPv6-compatible LSI   TBD:01          1/2^(TBD+2)
      Type 2 IPv6-compatible LSI   TBD:10          1/2^(TBD+2)
      IPv6 Address space           11              1/4

> Opinions?

IMHO the following changes are worth. If the WG agrees, I'll also 
modify the DNS draft accordingly.

Thanks,

--julien

---

From: [email-masked] (Tim Shepard)
Date: Thu Oct 14 09:25:00 2004

>                                    (binary)        Address Space

I would guess that if we get a prefix in the IPv6 address space
allocated for this purpose, it would start with 00 or 11.
In particular, looking at http://www.iana.org/assignments/ipv6-address-space
and thinking about what's already been allocated, it would seem to
make the best sense would be something inside of (binary) 0000 0000.

So I guess what I'm saying is that does not make sense to include the
first and last lines in that table.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 18 06:36:01 2004

> IPv6 LSI text of the -00 of the DNS draft, included below,

Ok.  Unless someone objects, IMHO you and Petri could edit in the
changes to the -01 versions.  To reduce secretariat load, it
may not be necessary to post an -01 version of the dns draft,
but it would be good if a pre-01 version was available prior
to the meeting.  But then, I'm afraid, we have to be prepared
at the meeting that some people have only read -00 version,
and adjust the presentation accordingly.

<actual changes removed as they are in the previous message
in this thread, other than App A text:>

> bits come from the hash of the Host Identity.

Actually my suggestion was that there is no content differences
between Type 1 and Type 2, but that the difference is always
communicated by some external means.  In the DNS it is the type
field, in the HIP protocol the proposed SHT and DHT control fields.

Hence, I would rewrite the paragraph, and what followed, as follows:

--

Historically, the first two bits of a HIT were used to differentiate
between Type 1, Type 2, and IPv6 address formats.  This was changed
in October 2004, when the Working Group decided that all (currently
defined) HITs are 128-bit long.  Hence, a Type 1 HIT consists of
128 bits of the SHA-1 hash of the public key, and a Type 2 HIT consists
of a 64-bits long HAA field, followed by a 64-bits of the SHA-1 hash.
[The format of the HAA field is left undefined in this document.]

In this document, we additionally define an internal IPv6-compatible 
LSI-
representation format, to be used within the legacy IPv6-compatible
API (e.g., socket over AF_INET6).  The format of these IPv6-compatible
LSIs is designed to avoid the most commonly occurring IPv6 addresses
in RFC3596 [9].  An IPv6-compatible LSI representation of a HIT can be
easily computed by replacing the first TBDth bits of the HIT by
the TBD bits long prefix "0xTBD".  Accordingly, this specification also
RECOMMENDS that conforming implementations ignore the TBD prefix bits
when comparing HITs for equality; see Section XXX.

--

As the text above is supposed to be in an appendix, we have to add
in the HIT section of the base document text like the following:

--

When comparing HITs for equality, it is RECOMMENDED that
conforming implementations ignore the TBD top most bits.
This is to allow better compatibility for legacy IPv6 applications;
see Appendix A.  However, independent of how many bits are
actually used for HIT comparison, it is also RECOMMENDED that
the final equality decision is based on the public key and not
the HIT, if possible.  See also Section <LSI> for related discussion.

--

<HIT space allocation table snipped.>

I don't think we need the HIT space allocation table, but separately
seek for IANA registration for the prefix, perhaps writing a brief
separate document (one page long?) that defines IPv6 LSI usage
and the prefix.

> IPv6 LSI bits? If so, replace the last sentence and the table of the

IMHO, no.  If we decide to get rid of the prefix, IMHO we should
get rid of it altogether, and use all of the 128 bits of a (Type 1)
HIT for hash.

> modify the DNS draft accordingly.

Hence, opinions, others?

--Pekka