Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00

["Henderson, Thomas R" <[e-mail]>]

> >
> > I think we should really explore this idea more but let's
> do so in the more RFC4423bis context as discussed in the
> other thread.  I wasn't objecting to the idea per se, but
> just that we should not slip it into this draft if it is not
> really recognized as a part of HIP today.
>
> Actually, we used to have a milestone about this in the
> charter, but it
> was removed last July when the WG's conclusion was that
> transformations
> would be context specific. So, this already is recognized as
> part of the
> HIP today.

Can you point me to a document that shows where this is recognized as part of HIP today?

>
> > I see pros and cons to non-ORCHID HITs:
> > - pro:  can be designed to be hierarchical or formatted as
> needed.  Can they even be IPv6 addresses?
> > - con:  HITs are no longer unique.  It is really the
> certificate which is the unique identifier.
> > It does seem more flexible and may have deployment
> advantages.  Does it solve the ACL problem with current HITs
> (that they are non-aggregatable)?  It could lead to
> aggregatable HITs but then the ACL will need to know the
> authorizing enrollment server for those HITs, and check CERTs.
>
> These questions are good to be explored on RFC4423bis, but we
> don't need
> the answers to proceed with the RELOAD instance spec, so I would not
> delay the instance spec by making it depend on RFC4423bis.
>
> Anyhow, we are not changing anything fundamental in HIP, and
> having this
> property we can make HIP meet the different requirements that people
> building overlays have.
>

I disagree that this changes anything fundamental:  RFC5201, section 3.1:
3.1.  Host Identity Tag (HIT)

   The Host Identity Tag is a 128-bit value -- a hashed encoding of the
   Host Identifier.

I am not opposed to relaxing this in principle but I do not recall that we have agreed on how to do this.

- Tom