[Hipsec-rg] 答复: Hierarchical HITs

Hi:

If we don't consider the performance issue, certificates will be a very good
solution as we can put nearly everything we want into a certificate. But the
contents in a certificate are not structured as well as the contents in a
HIP header. The position of the same parameter may change in different
certificates. In this case, we have to locate the parameter through its
index, and thus the performance of system is influenced. 

Therefore, it is reasonable to put additional information in certificates.
But we should find a fixed position in HIP header for information which is
important or frequently used so that it is easier for us to design hardware
to increase the processing speed of the information. 

Maybe we should focus our discussion on whether hierarchical information is
important enough.

This is just my humble personal opinion. 

Best wishes,

Dacheng Zhang

> ??: Re: [Hipsec-rg] Hierarchical HITs
> 
> Andrew McGregor kirjoitti:
> > But you are just describing the internal workings of a 
> certificate. So 
> > why dos the HIP certificates work not suffice?
> > 
> 
> Yes, simple certificate stating that this HI belongs to the 
> signers domain, carried in CERT parameter, would suffice for 
> the ACL purposes at least in my opinion.
> 
> > On 22/01/2009, at 16:27, Xu Xiaohu <xuxh at huawei.com> wrote:
> > 
> >> [please skip the previous email]
> >>
> >> Oleg.
> >>
> >> Does every host in HIP architecture need a FQDN? (btw, there  were 
> >> similar threads in RRG,see  
> >> http://www.ops.ietf.org/lists/rrg/2008/msg02050.html)
> >>
> >> If the access control is based on HIT, the firewall maybe need to 
> >> maintain an ACL with a huge amount of flat HIT entries. If 
> the access 
> >> control is based on domain name , it will need to do lookup to 
> >> resolve each HIT to FQDN in order to determine the domain 
> name.  Both 
> >> of them mean a huge burden on firewalls. Besides, the latter will 
> >> aslo introduce a DDoS attack risk.
> >>
> >> With hierarchical HIT(Adminstrative Domain(AD) ID+ Hash (public 
> >> key+AD ID)), the firewall can simply do access control 
> based on the 
> >> AD ID.
> >>
> >> Xiaohu
> >>
> >>> -----????-----
> >>> ???: Xu Xiaohu [mailto:xuxh at huawei.com]
> >>> ????: 2009?1?22? 11:19
> >>> ???: 'Oleg Ponomarev'; 'Zhang Dacheng'
> >>> ??: 'hipsec-rg at listserv.cybertrust.com'
> >>> ??: re: [Hipsec-rg] Hierarchical HITs
> >>>
> >>>
> >>>> Once again, we already have hierarchical identities (e.g.
> >>>> domain names) and I do not see the reasons to introduce 
> yet another 
> >>>> hierarchical space.
> >>>> Of course, this is just my opinion.
> >>>
> >>> Oleg.
> >>>
> >>> Does every host in HIP architecture need a FQDN? (btw, there were 
> >>> similar threads n RRG,see
> >>> http://www.ops.ietf.org/lists/rrg/2008/msg02050.html)
> >>>
> >>> If the access control is based on HIT, the firewall needs to 
> >>> maintain an ACL with a huge amount of flat HIT entries. 
> Both of them 
> >>> mean a huge burden on firewalls. Besides, the former will aslo 
> >>> introduce a DDoS attack risk., when a firewall enforces access 
> >>> control based on domain name , it will need to do lookup 
> to resolve 
> >>> each HIT to FQDN in order to determine its domain name.
> >>>
> >>> With hierarchical HIT (Adminstrative Domain(AD) ID+ Hash (public 
> >>> key+AD ID)), the firewall can simply do access control 
> based on the 
> >>> AD ID.
> >>>
> >>> Xiaohu
> >>
> >> _______________________________________________
> >> Hipsec-rg mailing list
> >> Hipsec-rg at listserv.cybertrust.com
> >> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
> > _______________________________________________
> > Hipsec-rg mailing list
> > Hipsec-rg at listserv.cybertrust.com
> > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
> 
> 
> --
> BR,
> Samu
> 
> "Programmer is an organism that changes caffeine into code"
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
> 