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

[Ari Keranen <[e-mail]>]

Henderson, Thomas R wrote:
>>> I think we should really explore this idea more but let's4
>> 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?

The WG overlay documents, HIP BONE and RELOAD instance, have reflected 
this. Yes, they are not RFCs, but my point was that this is nothing we 
have introduced here out of the blue.

>>> 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.

OK, that's true, only the "ORCHID mode" identifiers are strictly HITs in 
that sense so we could call the generic RELOAD mode IDs something else. 
Perhaps RITs?

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

When we removed the generic transformation milestone from the charter, 
the conclusion was that the transformation (or Node ID generation) would 
be done in different ways depending on the peer protocol and thus better 
defined in the instance specs. And that's what the RELOAD instance spec 
now does. Also, if the ID is generated as the RELOAD draft proposes (SHA 
of the public key; which you could use also as the the Host ID), it 
actually even fits nicely to the definition of HIT.


Cheers,
Ari