[Hipsec-rg] Hierarchical HITs (Was: reverse DNS lookups of HITs)

[shengjiang at huawei.com (JiangSheng 66104)]

> JiangSheng 66104 wrote:
> >>> (See http://tools.ietf.org/id/draft-jiang-hiprg-hhit-arch-01.txt.)
> >> I did not read it thoroughly, but don't you make locators from the
> >> permanent identifiers? I.e. when I change my network provider I
> >> will have
> >> to change the "HIP management domain" part in HIT?
> >
> > Yes and no. Yes, when one change networks, it need to get a different HIP
> management domain, even maybe generate a new HIT based on the new HIP management
> domain. This will give a big advantage for ISP management on HITs. However,
> other mechanisms may be used to support the usage of permanent user HITs,
> mechanisms similar to support CoA and HA in mobile IP senarios.
> >
> 
> For me this sounds weird. If you think mobility, the point in the HIT is
> to remain the same from network to network so that the host can be
> identified. If the HIT changes from network to network the HIT loses its
> meaning as identifier. Did I miss something with the ISP managed HITs or
> what is the case here?

It seems my early explanation was misleading. I am giving another try here with example of real life identity.

Like a person should receive an identity from local authority administration, a network device should receive an HIT from network management authorization. Real life identity has country code, state code, local code; an HIT (in our proposed HHIT architecture) has HIP management tags, which are aggregatable. A person can take his identity card with him wherever he moves; a network device can also take its HIT with it whatever network it moves. However, a Londoner with a London issued identity card will be identified as a Londoner wherever he is; a BT customer device with a HIT issued by BT will be identified as a BT customer device.

If a Londoner wants to change its permanent address or citizenship to become a New Yorker, he is allowed to do so, and he will get a new identity card issued by New York local authority administration, the new identity card will have US country code, New York code, and his new society code. For the HHIT case, if a user wants to switch his service provider from BT to AT&T, he can do so by ask a new HIT from AT&T for his network device, this new HIT will contains the AT&T's HIP management tag. With new identity card, the man will be identified as a New Yorker wherever he travels; with new HIT, the user device will be identified as an AT&T customer device.

For consistency, the man's new identity will be linked with his old one to show this is the same people. New HIP mechanism may be developed, to support like new HIT and old HIT together, like the relationship between CoA and HA.

Back to the initial discuss topic, ACL. One ACL of a certain service, can have one simple item to represent a group of HIT rather than to store every HIT in flat-structured HIT architecture. The secure issues are solved in the improved HHIT model, which include management domain tag as a part of input for hash algorithm in HIT generation. In this model, if there is a service open for all BT customers, the ACL of this service just needs to remember BT's HIP management tag and BT's certification path. The ACL has been configured with BT's trust anchor. Then, it can verify whether a device with BT's HIT also owns a validated BT certificate. The detail mechanism can be similar to SEND, described in Section 6, RFC3971. I don't think this architecture prevent the usage of names in ACL. As Henderson stated, one can free to use whatever name in the certificate as the name in the ACL instead of management tag.

By proposed this architecture, we are aiming to solve the scalability issue of HIT, which is discussed earlier in this thread, as quoted below. This architecture brings proper aggregation into HIP, we believe. HHIT is aggregatable, in a short.

Hope this answer Varjonen, Oleg and Henderson.

> > > I see how one could technically build such a name server, but I'm 
> > > wondering about the scalability of it and how it would
> > > operationally be deployed.
> >
> > I guess one modern server could keep like ten million records in 
> > RAM? How many base exchanges can it do per second? Reverse DNS 
> > updates are rare anyway.
> >
> > When HIP gets widely deployed and there are millions of users, we 
> > might hope to use more resources :)
> 
> This type of question is precisely what this research group's primary
> charter is to answer, in my opinion.  What are the consequences of
> deploying HIP on a large scale in the Internet?  If it means that we
> will have a few root servers handling reverse DNS queries for all hosts,
> without any aggregation, how will that architecture scale, and how will
> the deployment incentives work?  Or, if that turns out to be a bad idea,
> what are the practical alternatives that allow someone to write
> domain-name-based ACLs?

Best regards,

Sheng