Oleg Ponomarev wrote:
Hi! On Thu, 23 Apr 2009, Robert Moskowitz wrote:Exactly, one of the ideas was to get 1.0.0.1.0.0.2.ip6.arpa delegated, then anyone could update the PTR for the Host Identity.Anyone????? Sounds bad, insecure.Of course, anyone posessing the private part of the Host Identity.
And how do you 'prove' this? Been a long time since I looked at DYNDNS....
i.e. if my HIT is 2001:1e:574e:2505:264a:b360:d8cc:1d75, the server allows me to update 5.7.d.1.c.c.8.d.0.6.3.b.a.4.6.2.5.0.5.2.e.4.7.5.e.1.0.0.1.0.0.2.ip6.arpa.A HIP host registers with the owner of 1.0.0.1.0.0.2.ip6.arpa. This establishes ownership of the HIT and then the entry gets updated. This can be covered in an Informational BCP doc.So given that there IS an RFC for the ORCHID prefix, who gets to run this domain?Could it be something similar to root-servers? Now ORCHID prefix is not HIP-specific and it might be difficult to get ip6.arpa, if we require HIP to manage it.
There would have to be multiple ways to update it, via one owner. Secure ways always win out over insecure ways. So if foo sends in an update via insecure SHIM6, say, then bar comes in with the same ORCHID but via HIP proving it is a HIT, the HIT replaces the SHIM6? Does SHIM6 use ORCHIDs; just grabbing another protocol out of the air here.... If two secure protocols come in the same ORCHID it is first come first own.
We have some operational experience in HIIT for local nameservers.
So you become the new ISI? Neat! Actually, this makes a lot of sense to give it, at least at first, to a group like HIIT.
How do we get the ip6.arpa owner to deligate it?With usual (assigned) IP address space it is a trivial technical operation, in this case we might need an I-D/RFC, I guess.
Yes, we will need a ORCHID reverse lookup ID (if we stay with ORCHIDs, given the need to change even ORCHID to support other hashes), and point to a HIT-to-IP ID for one mechanism used by the owner of the domain.
There was some discussion in hiprg mailing list last December.
I will try and dig it out.
