From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Sun, 01 Feb 2009 10:01:18 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEtleSBSZXZvY2F0aW9uIElzc3Vl?= In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BD39@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <003f01c98410$f93282b0$480c6f0a@china.huawei.com> Hi, Very happy to get your feedback. Actually, the requirements of HIT mapping are not limited to ACLs. There are still some other scenarios where HIT mapping is needed. For example, the components of a current business application can be developed independently, maintained by different organizations, combined at runtime, and communicate with asynchronous messages. A typical collaboration between such two components can last from days to months. Therefore, in such a scenario, change of HITs can be common.(Please refer to the literature of SaaS (software as a service) and SOA (service oriented architecture) for more details.) When a host changes its HIT, there should be a way to inform other collaborating asynchronous hosts of the change. DNS is a potential solution. But my concern is whether every host in the HIP architecture should be associated with a FQDN. In this point, I agree with Andrew. https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-January/000616.html . If a host only consumes services provided by other hosts, it is not reasonable to force the host to apply and maintain an FQDN. > > Currently, I am thinking whether > it is a good > > way to achieve this objective by extending the functionality of > > Rendezvous servers. DNS can also be a candidate. As I mentioned previously, I am not trying to introduce a "new" third party. It is fantastic if DNS service can be provided. But in the cases there is no FQDN, we can try to solve the HIT mapping issue by extending the functionality of Rendezvous servers. In addition, a HIT can only last for a very short period (maybe minutes), while it may take time for DNS to refresh information. In this case, the idea of extending of Rendezvous servers seems to be more valuable. What do you think about it? Cheers Dacheng > ???: Henderson, Thomas R [mailto:thomas.r.henderson at boeing.com] > ????: 2009?1?31? 2:12 > ???: Zhang Dacheng; hipsec-rg at listserv.cybertrust.com > ??: RE: [Hipsec-rg] Key Revocation Issue > > > > > -----Original Message----- > > From: Zhang Dacheng [mailto:zhangdacheng at huawei.com] > > Sent: Tuesday, January 20, 2009 11:30 PM > > To: hipsec-rg at listserv.cybertrust.com > > Subject: [Hipsec-rg] Key Revocation Issue > > > > Hello everyone: > > > > When reading IETF HIP related documents, I found there were > still lots > > of things left for us to explore in the key revocation > issues. Because > > of security reasons, the cryptographic key held by a host normally > > should be changed after being used for a certain period. In > this case, > > the HIT needs to be changed too. > > > > Assume there is a host, A, which has changed its HIT. It may be not > > practical for A to notify all the hosts which hold the old HIT of A > > about the change, and this can cause several problems. For example, > > when A attempts to use the new HIT to access a server which > uses the > > old HIT of A in its ACL, the request may be rejected. In > addition, a > > user holding the old HIT will find it is very difficult (if it is > > possible) to locate A. > > Therefore, I think there should be a third party in the HIP > > architecture to provide the mapping service between the old > HITs and > > the associated new HITs. Currently, I am thinking whether > it is a good > > way to achieve this objective by extending the functionality of > > Rendezvous servers. DNS can also be a candidate. > > > > What do you think about it? Hope to get your comments. > > > Hi Dacheng, > > I didn't respond earlier to your post but I don't really have > anything much to add to my previous comments that ACLs > probably shouldn't be > HIT-based: > https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-Janua > ry/000581. > html > > If your use case is that HITs are changing, all the more > reason to not base the ACLs or application stable names as > HITs. So, I'm not sure a new third party is necessary (we > already have the DNS). > > - Tom From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Fri, 30 Jan 2009 10:11:49 -0800 Subject: [Hipsec-rg] Key Revocation Issue In-Reply-To: <001901c97b9a$1c233820$480c6f0a@china.huawei.com> References: <001701c97b77$5c494480$480c6f0a@china.huawei.com> <001901c97b9a$1c233820$480c6f0a@china.huawei.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BD39@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: Zhang Dacheng [mailto:zhangdacheng at huawei.com] > Sent: Tuesday, January 20, 2009 11:30 PM > To: hipsec-rg at listserv.cybertrust.com > Subject: [Hipsec-rg] Key Revocation Issue > > Hello everyone: > > When reading IETF HIP related documents, I found there were > still lots of > things left for us to explore in the key revocation issues. Because of > security reasons, the cryptographic key held by a host > normally should be > changed after being used for a certain period. In this case, > the HIT needs > to be changed too. > > Assume there is a host, A, which has changed its HIT. It may be not > practical for A to notify all the hosts which hold the old > HIT of A about > the change, and this can cause several problems. For example, when A > attempts to use the new HIT to access a server which uses the > old HIT of A > in its ACL, the request may be rejected. In addition, a user > holding the old > HIT will find it is very difficult (if it is possible) to locate A. > Therefore, I think there should be a third party in the HIP > architecture to > provide the mapping service between the old HITs and the > associated new > HITs. Currently, I am thinking whether it is a good way to > achieve this > objective by extending the functionality of Rendezvous > servers. DNS can also > be a candidate. > > What do you think about it? Hope to get your comments. > Hi Dacheng, I didn't respond earlier to your post but I don't really have anything much to add to my previous comments that ACLs probably shouldn't be HIT-based: https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-January/000581. html If your use case is that HITs are changing, all the more reason to not base the ACLs or application stable names as HITs. So, I'm not sure a new third party is necessary (we already have the DNS). - Tom From: xuxh at huawei.com (Xu Xiaohu) Date: Fri, 23 Jan 2009 12:06:23 +0800 Subject: [Hipsec-rg] =?gb2312?b?IHJlOiAgtPC4tDogILTwuLQ6IEtleSBSZXZvY2F0?= =?gb2312?b?aW9uIElzc3Vl?= In-Reply-To: <24C851CC-4CB6-4E6F-9A5A-E418F4B1EBE4@indranet.co.nz> Message-ID: <001b01c97d0f$f4cc2210$670c6f0a@china.huawei.com> Hi Andrew, > It isn't reasonable to assume that each host is associated > with a FQDN (unless we make it so, for instance by > constructing said FQDN out of the HIT), for the majority of > devices. For example, is my cellphone associated with an > FQDN? If so, is that FQDN at all useful for access, > identification or authorisation? Probably not, since it is > under the control of the cellphone carrier; they might be > able to use it for some of those purposes, but I can't. > > I believe it to be a design goal of HIP that it should be > useful without connectivity to the DNS; DNS record formats > and packets may be useful, but HIP itself should not require > that any host have an FQDN nor any ability to do DNS queries > (except perhaps by querying its immediate HIP peers... and > even then, only for information about those peers themselves, > in zeroconf style). Thanks for your comment and I agree with your opinion. When source host got the HIT of the destination host, the HIT needs to be resolved to locator through some id/locator mapping system. If the HIT has no organizational structure, who will run this mapping system? Isn't it lack of business incentive or security/trust boundary? Xiaohu > > Hi, > > > > I absolutely agree that FQDNs cannot directly be used for session > > authentication etc. But we need to clarify that the original > > objective of designing HIP is separation of IDs and locators rather > > than security. I agree security is an important > functionality provided > > by HIP. But I am not convinced that HITs cannot be taken placed by > > FQDNs just because HIT can be used for security purposes. > If so, why > > cannot we just associate with each FQDN with a PKI > certificate? There > > has been lots of work on session authentication using certificates. > > This solution seems much easier to be achieved than modifying the > > protocol stack. > > > > In addition, do you have any idea about whether it is reasonable to > > assume that each HIP host is associated with a FQDN? > > > > Best wishes, > > > > Dacheng Zhang > > > > > >> Excerpts from Zhang Dacheng on Thu, Jan 22, 2009 10:43:02AM +0800: > >>> I agree that it is an intuitive solution to solve the key > >> revocation > >>> issue with DNS. However, my concern is whether it is > >> reasonable for us > >>> to assume that every host has a FQDN. If yes, the > >> importance of HIP is > >>> largely weakened. We can use FQDN rather than HI to achieve the > >>> separation of ID from Locator. > >> > >> As far as I can see this isn't true. Different "identification" > >> functions have different needs. You can use a FQDN as an > identifier > >> for initial discovery of a location, but you cannot use it for > >> session authentication or control. To start with you would be > >> subject to man-in-the-middle attacks. > >> > >> Scott > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg at listserv.cybertrust.com > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg From: andrew at indranet.co.nz (Andrew McGregor) Date: Fri, 23 Jan 2009 16:15:38 +1300 Subject: [Hipsec-rg] =?utf-8?b?562U5aSNOiAg562U5aSNOiBLZXkgUmV2b2NhdGlv?= =?utf-8?q?n_Issue?= In-Reply-To: <003501c97d07$13d8fb00$480c6f0a@china.huawei.com> References: <003501c97d07$13d8fb00$480c6f0a@china.huawei.com> Message-ID: <24C851CC-4CB6-4E6F-9A5A-E418F4B1EBE4@indranet.co.nz> It isn't reasonable to assume that each host is associated with a FQDN (unless we make it so, for instance by constructing said FQDN out of the HIT), for the majority of devices. For example, is my cellphone associated with an FQDN? If so, is that FQDN at all useful for access, identification or authorisation? Probably not, since it is under the control of the cellphone carrier; they might be able to use it for some of those purposes, but I can't. I believe it to be a design goal of HIP that it should be useful without connectivity to the DNS; DNS record formats and packets may be useful, but HIP itself should not require that any host have an FQDN nor any ability to do DNS queries (except perhaps by querying its immediate HIP peers... and even then, only for information about those peers themselves, in zeroconf style). Andrew On 23/01/2009, at 4:02 PM, Zhang Dacheng wrote: > Hi, > > I absolutely agree that FQDNs cannot directly be used for session > authentication etc. But we need to clarify that the original > objective of > designing HIP is separation of IDs and locators rather than > security. I > agree security is an important functionality provided by HIP. But I > am not > convinced that HITs cannot be taken placed by FQDNs just because HIT > can be > used for security purposes. If so, why cannot we just associate with > each > FQDN with a PKI certificate? There has been lots of work on session > authentication using certificates. This solution seems much easier > to be > achieved than modifying the protocol stack. > > In addition, do you have any idea about whether it is reasonable to > assume > that each HIP host is associated with a FQDN? > > Best wishes, > > Dacheng Zhang > > >> Excerpts from Zhang Dacheng on Thu, Jan 22, 2009 10:43:02AM +0800: >>> I agree that it is an intuitive solution to solve the key >> revocation >>> issue with DNS. However, my concern is whether it is >> reasonable for us >>> to assume that every host has a FQDN. If yes, the >> importance of HIP is >>> largely weakened. We can use FQDN rather than HI to achieve the >>> separation of ID from Locator. >> >> As far as I can see this isn't true. Different "identification" >> functions have different needs. You can use a FQDN as an >> identifier for initial discovery of a location, but you >> cannot use it for session authentication or control. To >> start with you would be subject to man-in-the-middle attacks. >> >> Scott >> _______________________________________________ >> 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 > From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Fri, 23 Jan 2009 11:02:50 +0800 Subject: [Hipsec-rg] =?gb2312?b?ILTwuLQ6ICC08Li0OiBLZXkgUmV2b2NhdGlvbiBJ?= =?gb2312?b?c3N1ZQ==?= In-Reply-To: <20090122132950.GA1342@cisco.com> Message-ID: <003501c97d07$13d8fb00$480c6f0a@china.huawei.com> Hi, I absolutely agree that FQDNs cannot directly be used for session authentication etc. But we need to clarify that the original objective of designing HIP is separation of IDs and locators rather than security. I agree security is an important functionality provided by HIP. But I am not convinced that HITs cannot be taken placed by FQDNs just because HIT can be used for security purposes. If so, why cannot we just associate with each FQDN with a PKI certificate? There has been lots of work on session authentication using certificates. This solution seems much easier to be achieved than modifying the protocol stack. In addition, do you have any idea about whether it is reasonable to assume that each HIP host is associated with a FQDN? Best wishes, Dacheng Zhang > Excerpts from Zhang Dacheng on Thu, Jan 22, 2009 10:43:02AM +0800: > > I agree that it is an intuitive solution to solve the key > revocation > > issue with DNS. However, my concern is whether it is > reasonable for us > > to assume that every host has a FQDN. If yes, the > importance of HIP is > > largely weakened. We can use FQDN rather than HI to achieve the > > separation of ID from Locator. > > As far as I can see this isn't true. Different "identification" > functions have different needs. You can use a FQDN as an > identifier for initial discovery of a location, but you > cannot use it for session authentication or control. To > start with you would be subject to man-in-the-middle attacks. > > Scott > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg at listserv.cybertrust.com > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Fri, 23 Jan 2009 10:27:25 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEhpZXJhcmNoaWNhbCBISVRz?= In-Reply-To: <49781019.9010504@helsinki.fi> Message-ID: <002e01c97d02$21837640$480c6f0a@china.huawei.com> 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 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 > From: swb at employees.org (Scott Brim) Date: Thu, 22 Jan 2009 08:29:50 -0500 Subject: [Hipsec-rg] =?utf-8?b?562U5aSNOiBLZXkgUmV2b2NhdGlvbiBJc3N1ZQ==?= In-Reply-To: <002001c97c3b$255a9d60$480c6f0a@china.huawei.com> References: <002001c97c3b$255a9d60$480c6f0a@china.huawei.com> Message-ID: <20090122132950.GA1342@cisco.com> Excerpts from Zhang Dacheng on Thu, Jan 22, 2009 10:43:02AM +0800: > I agree that it is an intuitive solution to solve the key revocation issue > with DNS. However, my concern is whether it is reasonable for us to assume > that every host has a FQDN. If yes, the importance of HIP is largely > weakened. We can use FQDN rather than HI to achieve the separation of ID > from Locator. As far as I can see this isn't true. Different "identification" functions have different needs. You can use a FQDN as an identifier for initial discovery of a location, but you cannot use it for session authentication or control. To start with you would be subject to man-in-the-middle attacks. Scott From: samu.varjonen at helsinki.fi (Samu Varjonen) Date: Thu, 22 Jan 2009 08:20:09 +0200 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <6E14FE72-1FFF-4B21-840C-59C0061FFC7E@indranet.co.nz> References: <002b01c97c41$5ad55a60$670c6f0a@china.huawei.com> <6E14FE72-1FFF-4B21-840C-59C0061FFC7E@indranet.co.nz> Message-ID: <49781019.9010504@helsinki.fi> 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 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" From: andrew at indranet.co.nz (Andrew McGregor) Date: Thu, 22 Jan 2009 17:10:31 +1300 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <002b01c97c41$5ad55a60$670c6f0a@china.huawei.com> References: <002b01c97c41$5ad55a60$670c6f0a@china.huawei.com> Message-ID: <6E14FE72-1FFF-4B21-840C-59C0061FFC7E@indranet.co.nz> But you are just describing the internal workings of a certificate. So why dos the HIP certificates work not suffice? On 22/01/2009, at 16:27, Xu Xiaohu 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 From: xuxh at huawei.com (Xu Xiaohu) Date: Thu, 22 Jan 2009 11:27:29 +0800 Subject: [Hipsec-rg] Hierarchical HITs Message-ID: <002b01c97c41$5ad55a60$670c6f0a@china.huawei.com> [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 From: xuxh at huawei.com (Xu Xiaohu) Date: Thu, 22 Jan 2009 11:18:35 +0800 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: Message-ID: <002a01c97c40$1d05f290$670c6f0a@china.huawei.com> > 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 From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Thu, 22 Jan 2009 10:43:02 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEtleSBSZXZvY2F0aW9uIElzc3Vl?= In-Reply-To: Message-ID: <002001c97c3b$255a9d60$480c6f0a@china.huawei.com> Hi: I agree that it is an intuitive solution to solve the key revocation issue with DNS. However, my concern is whether it is reasonable for us to assume that every host has a FQDN. If yes, the importance of HIP is largely weakened. We can use FQDN rather than HI to achieve the separation of ID from Locator. If no, we need to consider the key revocation issue for the hosts which do not have FQDNs since every host more or less needs to deal with this problem. That is why I mentioned that maybe the functionality of RVS server needs to be enhanced. It is just my personal opinions. Hope to have further discussions on this topic. Best regards Dacheng > -----????----- > ???: Oleg Ponomarev [mailto:oleg.ponomarev at hiit.fi] > ????: 2009?1?21? 23:31 > ???: Zhang Dacheng > ??: hipsec-rg at listserv.cybertrust.com > ??: Re: [Hipsec-rg] Key Revocation Issue > > Hello! On Wed, 21 Jan 2009, Zhang Dacheng wrote: > > > DNS server cannot directly be used to help a user holding a antique > > HIT access the host whose HIT has been changed, unless the user has > > got the FQDN (by reverse DNS lookup of HITs maybe) in advance. > > Why _user_ would need to access the host by its HIT? This is > required for legacy applications, but people should operate > with domain names, IMHO. > > -- > Regards, Oleg. > From: fu at cs.uni-goettingen.de (Xiaoming Fu) Date: Thu, 22 Jan 2009 00:16:55 +0100 Subject: [Hipsec-rg] Call for papers: ICNP 2009 Message-ID: <4977ACE7.8040806@cs.uni-goettingen.de> [Sincere apologies if you receive multiple copies of this CFP.] CALL FOR PAPERS ICNP 2009 17th IEEE International Conference on Network Protocols October 13-16, 2009 Princeton, New Jersey, USA http://www.ieee-icnp.org/2009 ICNP, the IEEE International Conference on Network Protocols is the premier conference covering all aspects of network protocols. ICNP will be held in its seventeenth year at Princeton, New Jersey from October 13-16th, 2009. Papers with significant research contributions on network protocols are solicited for submission. Papers related to all aspects of network protocols including design, implementation, analysis, performance and specification are relevant. Papers must not be previously published nor under review in any other conference or journal. Only original papers that have not been published previously or submitted for publication and under review by another conference or journal elsewhere can be submitted. Papers containing plagiarized material will be subject to the IEEE Plagiarism policy and will be rejected without review. Topics of interest include, but are not limited to: ? Protocol design, implementation, testing and analysis. ? Measurement studies of protocol performance. ? Protocols for wireless ad hoc and sensor networks. ? Protocols for peer-to-peer networks. ? Protocols for specific functions such as routing, flow/congestion control, network management. ? Protocols for security, survivability and fault-tolerance. Papers must be directly relevant to protocols. Papers on general networking where protocols are only a secondary focus will be considered only if they are of exceptionally high quality. Papers will be subject to a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure blind reviewing, the authors' names and affiliations should not appear in the paper. Bibliographic references should protect the authors' anonymity. Papers should adhere to the IEEE format and should not be more than 10 pages. The font size should not be smaller than 10pt. Further instructions will be posted on the ICNP website (http://www.ieee-icnp.org/2009). Authors of accepted papers will be expected to register for the conference and the paper must be presented at the conference in order for the paper to appear in the conference proceedings. Important Dates: Abstract Submission: April 10, 2009 8:59 P.M. EDT Paper Submission: April 17, 2009 8:59 P.M. EDT (Hard Deadline) Notification of Acceptance: July 28, 2009 Camera Ready Version Due: September 4, 2009 Organizing Committee: Executive Committee: David Lee Ohio State University, USA (Chair) Mostafa Ammar Georgia Tech. USA Ken Calvert University of Kentucky, USA Teruo Higashino Osaka University, Japan Raymond Miller University of Maryland, USA General Chairs: K.K. Ramakrishnan AT & T Labs Research, USA Henning Schulzrinne Columbia University, USA Program Chairs: Timothy Griffin University of Cambridge, U.K. Srikanth V. Krishnamurthy University of California, Riverside, USA For more details, visit the conference webpage: http://www.ieee-icnp.org/2009 Regards, Xiaoming Fu IEEE ICNP'09 Publicity Chair From: shengjiang at huawei.com (JiangSheng 66104) Date: Thu, 22 Jan 2009 04:28:38 +0800 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: References: <001701c97b77$5c494480$480c6f0a@china.huawei.com> Message-ID: > 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. Hi, Oleg, As I have stated several times, I guess you agreed on this too, hierarchical HIT has aggregatable advantages comparing to flat-structure HIT. It is other discussion topic whether this aggregatable is not an advantage HIT architecture needs or HIT architecture would choose depend on other hierarchical identity systems when aggregation is requested. And again, what I propose is a HIT architecture that supports both hierarchical and flat-structure HIT. Users can choose in different scenarios or their prefer. Best regards, Sheng From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Wed, 21 Jan 2009 17:30:45 +0200 (EET) Subject: [Hipsec-rg] Key Revocation Issue In-Reply-To: <001b01c97bcf$a0680c70$480c6f0a@china.huawei.com> References: <001b01c97bcf$a0680c70$480c6f0a@china.huawei.com> Message-ID: Hello! On Wed, 21 Jan 2009, Zhang Dacheng wrote: > DNS server cannot directly be used to help a user holding a antique HIT > access the host whose HIT has been changed, unless the user has got the > FQDN (by reverse DNS lookup of HITs maybe) in advance. Why _user_ would need to access the host by its HIT? This is required for legacy applications, but people should operate with domain names, IMHO. -- Regards, Oleg. From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Wed, 21 Jan 2009 16:43:04 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <001701c97b77$5c494480$480c6f0a@china.huawei.com> References: <001701c97b77$5c494480$480c6f0a@china.huawei.com> Message-ID: Hi! On Wed, 21 Jan 2009, Zhang Dacheng wrote: > The scenario you mentioned is applicable as well. However, identity > lists are normally used by the simplest authorization systems. Please note "access certificate issued to that identity by the trusted CA" > I cannot let you access my medical records if you only can prove that > you are who you have claimed. You also need to tell me where you from, > whether you are a qualified doctor, etc. Note that it is the job of my > authentication system to verify your claims. If we apply it to your example, I present a hospital badge with my photo on it, then 1) you may verify that this is my photo 2) you may see that the hospital authorized me to treat you. 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. -- Regards, Oleg. From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Wed, 21 Jan 2009 21:53:23 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEtleSBSZXZvY2F0aW9uIElzc3Vl?= In-Reply-To: <4976D726.5020508@hiit.fi> Message-ID: <001b01c97bcf$a0680c70$480c6f0a@china.huawei.com> Hi: DNS server cannot directly be used to help a user holding a antique HIT access the host whose HIT has been changed, unless the user has got the FQDN (by reverse DNS lookup of HITs maybe) in advance. Additional authentication processes are needed so that DNS can guarantee only the owner of a HIT can modify its result. Cheers Dacheng > > Hi, > > > Hello everyone: > > > > When reading IETF HIP related documents, I found there were > still lots > > of things left for us to explore in the key revocation > issues. Because > > of security reasons, the cryptographic key held by a host normally > > should be changed after being used for a certain period. In > this case, > > the HIT needs to be changed too. > > > > Assume there is a host, A, which has changed its HIT. It may be not > > practical for A to notify all the hosts which hold the old HIT of A > > about the change, and this can cause several problems. For example, > > when A attempts to use the new HIT to access a server which > uses the > > old HIT of A in its ACL, the request may be rejected. In > addition, a > > user holding the old HIT will find it is very difficult (if > it is possible) to locate A. > > Therefore, I think there should be a third party in the HIP > > architecture to provide the mapping service between the old > HITs and > > the associated new HITs. Currently, I am thinking whether > it is a good > > way to achieve this objective by extending the functionality of > > Rendezvous servers. DNS can also be a candidate. > > > > What do you think about it? Hope to get your comments. > > what about just changing the HI record of the FQDN? Of > course, this does not solve the problem with static ACLs. From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Wed, 21 Jan 2009 17:00:49 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEtleSBSZXZvY2F0aW9uIElzc3Vl?= In-Reply-To: <4976D726.5020508@hiit.fi> Message-ID: <001a01c97ba6$c1e04da0$480c6f0a@china.huawei.com> Hi: DNS server cannot directly be used to help a user holding a antique HIT access the host whose HIT has been changed, unless the user has got the FQDN (by reverse DNS lookup of HITs maybe) in advance. Additional authentication processes are needed too, and so DNS can guarantee only the owner of a HIT can modify its result. Another concern is that should we assume that every host using HIT should be registered with DNS? > > Zhang Dacheng wrote: > > Hi, > > > Hello everyone: > > > > When reading IETF HIP related documents, I found there were > still lots > > of things left for us to explore in the key revocation > issues. Because > > of security reasons, the cryptographic key held by a host normally > > should be changed after being used for a certain period. In > this case, > > the HIT needs to be changed too. > > > > Assume there is a host, A, which has changed its HIT. It may be not > > practical for A to notify all the hosts which hold the old HIT of A > > about the change, and this can cause several problems. For example, > > when A attempts to use the new HIT to access a server which > uses the > > old HIT of A in its ACL, the request may be rejected. In > addition, a > > user holding the old HIT will find it is very difficult (if > it is possible) to locate A. > > Therefore, I think there should be a third party in the HIP > > architecture to provide the mapping service between the old > HITs and > > the associated new HITs. Currently, I am thinking whether > it is a good > > way to achieve this objective by extending the functionality of > > Rendezvous servers. DNS can also be a candidate. > > > > What do you think about it? Hope to get your comments. > > what about just changing the HI record of the FQDN? Of > course, this does not solve the problem with static ACLs. From: miika.komu at hiit.fi (Miika Komu) Date: Wed, 21 Jan 2009 10:04:54 +0200 Subject: [Hipsec-rg] Key Revocation Issue In-Reply-To: <001901c97b9a$1c233820$480c6f0a@china.huawei.com> References: <001901c97b9a$1c233820$480c6f0a@china.huawei.com> Message-ID: <4976D726.5020508@hiit.fi> Zhang Dacheng wrote: Hi, > Hello everyone: > > When reading IETF HIP related documents, I found there were still lots of > things left for us to explore in the key revocation issues. Because of > security reasons, the cryptographic key held by a host normally should be > changed after being used for a certain period. In this case, the HIT needs > to be changed too. > > Assume there is a host, A, which has changed its HIT. It may be not > practical for A to notify all the hosts which hold the old HIT of A about > the change, and this can cause several problems. For example, when A > attempts to use the new HIT to access a server which uses the old HIT of A > in its ACL, the request may be rejected. In addition, a user holding the old > HIT will find it is very difficult (if it is possible) to locate A. > Therefore, I think there should be a third party in the HIP architecture to > provide the mapping service between the old HITs and the associated new > HITs. Currently, I am thinking whether it is a good way to achieve this > objective by extending the functionality of Rendezvous servers. DNS can also > be a candidate. > > What do you think about it? Hope to get your comments. what about just changing the HI record of the FQDN? Of course, this does not solve the problem with static ACLs. From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Wed, 21 Jan 2009 15:30:17 +0800 Subject: [Hipsec-rg] Key Revocation Issue In-Reply-To: <001701c97b77$5c494480$480c6f0a@china.huawei.com> Message-ID: <001901c97b9a$1c233820$480c6f0a@china.huawei.com> Hello everyone: When reading IETF HIP related documents, I found there were still lots of things left for us to explore in the key revocation issues. Because of security reasons, the cryptographic key held by a host normally should be changed after being used for a certain period. In this case, the HIT needs to be changed too. Assume there is a host, A, which has changed its HIT. It may be not practical for A to notify all the hosts which hold the old HIT of A about the change, and this can cause several problems. For example, when A attempts to use the new HIT to access a server which uses the old HIT of A in its ACL, the request may be rejected. In addition, a user holding the old HIT will find it is very difficult (if it is possible) to locate A. Therefore, I think there should be a third party in the HIP architecture to provide the mapping service between the old HITs and the associated new HITs. Currently, I am thinking whether it is a good way to achieve this objective by extending the functionality of Rendezvous servers. DNS can also be a candidate. What do you think about it? Hope to get your comments. Cheers Dacheng From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Wed, 21 Jan 2009 11:21:32 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEhpZXJhcmNoaWNhbCBISVRz?= In-Reply-To: Message-ID: <001701c97b77$5c494480$480c6f0a@china.huawei.com> Hi: Maybe I didn?t explain my idea in the last email clearly. Sorry for that. I never say that authentication results based on HITs cannot be used for authorization. The scenario you mentioned is applicable as well. However, identity lists are normally used by the simplest authorization systems. Because identity-based authorization systems need to maintain a record for each user, they are not efficient in the management of a large amount of users. In order to solve the scalability issue and support more sophisticated AC policies, new types of authorization systems (such as attributed-based and role-based authorization systems) have been proposed and widely employed. In these systems, privileges cannot be granted based on or only based on the proof of the ownership of keys; additional information is needed. Let's consider a very simple example here. I cannot let you access my medical records if you only can prove that you are who you have claimed. You also need to tell me where you from, whether you are a qualified doctor, etc. Note that it is the job of my authentication system to verify your claims. Apart from the proof of the possession of keys, HHIT can provide additional hierarchal information which is required by many authorization systems. In another word, you can generate more flexible AC polices based on the information provided by HHITs. I think this is a benefit that HHIT introduces. > The fingerprints (and other biometrics) is "self-generated" > and does not have any hierarchy, but can be used for > authorization very well. I agree with it. However, this type of system is normally supported by powerful databases which maintain the attributes of users before they can actually authenticate themselves to the system. Therefore, I don't think that hierarchical information is useless in these systems. The only difference is that you need to provide the information before the process of authentication. I think the designers of fingerprint-based authentication systems might be very happy if they can find your hierarchical information from your biometrical features, because they can reduce the data maintained in the databases. Just a joke. Hope this email can answer your questions. Best Regards Dacheng > > Greetings! > > >> I think we should distinguish authorization (deciding whether to > >> grant > >> access) and authentication (verifying identity). > > > I think Sheng Jiang just indicates that the authentication results > > should be able to be used by authorisation systems. In any > un-trivial > > systems, access control (AC) is performed by authorisation > mechanisms, > > and authentication results do not mean a lot if they cannot be used > > for authorisation. HHITs can provide information about > administration > > domains, which may be valuable for authorisation systems to make AC > > assertions. > > Could you please elaborate why HIP-authentication cannot be > used for authorization? > > 1) HIP is used to verify the identity of the host (that the > host possesses the private key indeed) > > 2) The verified identity is used for the authorization > purposes: simply check that it is in the list of authorized > identities or request access certificate issued to that > identity by the trusted CA or whatever. > > > The fingerprints (and other biometrics) is "self-generated" > and does not have any hierarchy, but can be used for > authorization very well. > > -- > Regards, Oleg. From: tkoponen at iki.fi (Teemu Koponen) Date: Tue, 20 Jan 2009 23:35:44 +0200 Subject: [Hipsec-rg] =?utf-8?b?562U5aSNOiAgSGllcmFyY2hpY2FsIEhJVHM=?= In-Reply-To: <49717481.5030205@googlemail.com> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49717481.5030205@googlemail.com> Message-ID: <29389CC8-7215-4D82-A7B1-885CFF5EC5EA@iki.fi> On Jan 17, 2009, at 08:02 , Julien Laganier wrote: > If my identifier is bound with one entity in the hierarchy, then I'm > wondering what would be the advantage of using HHIT over traditional > DNS > names? For an example of benefits of hierarchical flat identifiers, see: http://www.cs.cmu.edu/~dga/papers/aip-sigcomm2008.pdf From: shengjiang at huawei.com (JiangSheng 66104) Date: Wed, 21 Jan 2009 05:26:07 +0800 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: References: <000301c97aa1$9071f300$480c6f0a@china.huawei.com> Message-ID: Hi, Oleg, Please don't take my initial meaning wrongly. I have no objection that HIP-authentication can be used for authorization, even the self-generated, non-hierarchical HIT. Actually, in some scenarios, such as for privacy purpose, it is more suitable than HHIT. If you read my draft, what I suggest is a hierarchical HIT architecture compatible with the flat-structured HIT architecture. In my proposal, hierarchical HIT and self-generated HIT are both supported. The advantage HHIT has is it carries more embedded information, its beloing information, and this belonging information can be verified too. It is useful for aggregation purpose. Best regards, Sheng ----- Original Message ----- From: Oleg Ponomarev Date: Tuesday, January 20, 2009 11:15 pm Subject: Re: [Hipsec-rg] Hierarchical HITs To: Zhang Dacheng Cc: hipsec-rg at listserv.cybertrust.com > Greetings! > > >> I think we should distinguish authorization (deciding whether to > grant>> access) and authentication (verifying identity). > > > I think Sheng Jiang just indicates that the authentication > results > > should be able to be used by authorisation systems. In any un- > trivial > > systems, access control (AC) is performed by authorisation > mechanisms, > > and authentication results do not mean a lot if they cannot be > used for > > authorisation. HHITs can provide information about administration > > domains, which may be valuable for authorisation systems to make > AC > > assertions. > > Could you please elaborate why HIP-authentication cannot be used > for > authorization? > > 1) HIP is used to verify the identity of the host (that the host > possesses > the private key indeed) > > 2) The verified identity is used for the authorization purposes: > simply > check that it is in the list of authorized identities or request > access > certificate issued to that identity by the trusted CA or whatever. > > > The fingerprints (and other biometrics) is "self-generated" and > does not > have any hierarchy, but can be used for authorization very well. > > -- > Regards, Oleg. > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg at listserv.cybertrust.com > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg > From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 20 Jan 2009 17:14:49 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <000301c97aa1$9071f300$480c6f0a@china.huawei.com> References: <000301c97aa1$9071f300$480c6f0a@china.huawei.com> Message-ID: Greetings! >> I think we should distinguish authorization (deciding whether to grant >> access) and authentication (verifying identity). > I think Sheng Jiang just indicates that the authentication results > should be able to be used by authorisation systems. In any un-trivial > systems, access control (AC) is performed by authorisation mechanisms, > and authentication results do not mean a lot if they cannot be used for > authorisation. HHITs can provide information about administration > domains, which may be valuable for authorisation systems to make AC > assertions. Could you please elaborate why HIP-authentication cannot be used for authorization? 1) HIP is used to verify the identity of the host (that the host possesses the private key indeed) 2) The verified identity is used for the authorization purposes: simply check that it is in the list of authorized identities or request access certificate issued to that identity by the trusted CA or whatever. The fingerprints (and other biometrics) is "self-generated" and does not have any hierarchy, but can be used for authorization very well. -- Regards, Oleg. From: zhangdacheng at huawei.com (Zhang Dacheng) Date: Tue, 20 Jan 2009 09:51:08 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEhpZXJhcmNoaWNhbCBISVRz?= In-Reply-To: Message-ID: <000301c97aa1$9071f300$480c6f0a@china.huawei.com> Hi! On Sat, 17 Jan 2009, Sheng Jiang wrote: > As I explained earlier, a self-issued identity means little. Will any > country allow entrance of a man whose identity card is issued by > himself only? I think we should distinguish authorization (deciding whether to grant access) and authentication (verifying identity). -- Regards, Oleg. _______________________________________________ Hipsec-rg mailing list Hipsec-rg at listserv.cybertrust.com https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg Hi, I think Sheng Jiang just indicates that the authentication results should be able to be used by authorisation systems. In any un-trivial systems, access control (AC) is performed by authorisation mechanisms, and authentication results do not mean a lot if they cannot be used for authorisation. HHITs can provide information about administration domains, which may be valuable for authorisation systems to make AC assertions. Best Regards, Dacheng Zhang From: shengjiang at huawei.com (JiangSheng 66104) Date: Tue, 20 Jan 2009 06:09:58 +0800 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <49717DCD.7050903@googlemail.com> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> <49717246.2060004@laposte.net> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> <49717DCD.7050903@googlemail.com> Message-ID: Hi, Julien, First of all, I have no objection that DNS names may be used as host identifiers in some scenarios. Then, comparing with DNS, there are at least two major advantages HHIT has, as far as I understand and consider, one, HHIT has embedded security information and easy for verification; two, HHIT is numeric with fixed length. It is much simpler and more effective for a host to process. Cheers, Sheng ----- Original Message ----- From: Julien Laganier Date: Saturday, January 17, 2009 6:42 am Subject: Re: [Hipsec-rg] Hierarchical HITs To: Sheng Jiang Cc: hipsec-rg at listserv.cybertrust.com > Sheng, > > Sheng Jiang wrote: > >> This is exactly the point; If a HHIT has the limitation that: > >> > >> - it is bound with one entity in the hierarchy compared to a > plain HIT > >> (like a DNS name is) > >> > >> - is not human readable compared to a DNS name (like a HIT is) > >> > >> Then why should I use a HHIT as a host identifier? I'm getting > all of > >> the disadvantages of HIT (not readable) or DNS name (bound to an > entity>> in the hierarchy) but none of their respective advantages, > i.e., not > >> being bound to an entity, or being readble... > > > > I don't think bound to an entity in the hierarchy is a > disadvantage at all. > > You haven't replied to my previous question which was "My question > was,If my identifier is bound with one entity in the hierarchy, > what would > be the advantage of using HHIT as host identifiers, compared to using > DNS names as host identifiers? " > > Now if this is not a disadvantage, and if it's actually the > functionality that you're searching for, why can't you simply use > domainnames as host identifiers. They have the advantage of being > humanreadable, and I do not see any domain name drawback to HHIT... > > --julien > From: julien.laganier.ietf at googlemail.com (Julien Laganier) Date: Fri, 16 Jan 2009 23:42:21 -0700 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> <49717246.2060004@laposte.net> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> Message-ID: <49717DCD.7050903@googlemail.com> Sheng, Sheng Jiang wrote: >> This is exactly the point; If a HHIT has the limitation that: >> >> - it is bound with one entity in the hierarchy compared to a plain HIT >> (like a DNS name is) >> >> - is not human readable compared to a DNS name (like a HIT is) >> >> Then why should I use a HHIT as a host identifier? I'm getting all of >> the disadvantages of HIT (not readable) or DNS name (bound to an entity >> in the hierarchy) but none of their respective advantages, i.e., not >> being bound to an entity, or being readble... > > I don't think bound to an entity in the hierarchy is a disadvantage at all. You haven't replied to my previous question which was "My question was, If my identifier is bound with one entity in the hierarchy, what would be the advantage of using HHIT as host identifiers, compared to using DNS names as host identifiers? " Now if this is not a disadvantage, and if it's actually the functionality that you're searching for, why can't you simply use domain names as host identifiers. They have the advantage of being human readable, and I do not see any domain name drawback to HHIT... --julien From: julien.laganier.ietf at googlemail.com (Julien Laganier) Date: Fri, 16 Jan 2009 23:02:59 -0700 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> Message-ID: <49717493.4010104@googlemail.com> Sheng Jiang wrote: >> Sheng Jiang wrote: >>>> [...] >>>> >>>> I just do not see the reasons to have a new hierarchical space of >>>> identifiers. We already have the Internet address space, domain names, SSL >>>> certificates and so on. Of course, I might be wrong. >>> >>> Yes, we have so many hierarchical identifiers already. They are hierarchical >>> for reasons: aggregative, even more important for management purpose. This >>> is particularly important for host identity. Will any country allow entrance >>> of a man whose identity card is issued by himself only? Will BT give >>> services access to a host/device that has its own arbitrary identity? >>> The purpose of an identity is to identify itself, the most important, its >>> belonging. Our proposal embeds this belonging information into HIT, make >>> the HIT meaningful. The receiver or network management plane can easily >>> validate it. >> >> If my identifier is bound with one entity in the hierarchy, then I'm >> wondering what would be the advantage of using HHIT over traditional DNS >> names? > > Good question, Julien. However, why do we have to using HHIT over DNS? You might have misunderstood my question. My question was, If my identifier is bound with one entity in the hierarchy, what would be the advantage of using HHIT as host identifiers, compared to using DNS names as host identifiers? > For my understanding, because flat-structure HIT is lack of hierarchy, the best > way to use it is with hierarchical domain name system. It is different for > HHIT case. The Hierarchical HIT can be used alone. With its HIP management > tag, a HHIT can have most of meaning of a domain name only except that it is > non-human-readable. This is exactly the point; If a HHIT has the limitation that: - it is bound with one entity in the hierarchy compared to a plain HIT (like a DNS name is) - is not human readable compared to a DNS name (like a HIT is) Then why should I use a HHIT as a host identifier? I'm getting all of the disadvantages of HIT (not readable) or DNS name (bound to an entity in the hierarchy) but none of their respective advantages, i.e., not being bound to an entity, or being readble... > It can be mapped to locator directly. Not sure I understand what you mean by 'directly' here... If you mean that I do not need to interogate more than one system to be able to contact a node, AFAICS a plain domain name also has this property. Cheers, --julien From: julien.laganier.ietf at googlemail.com (Julien Laganier) Date: Fri, 16 Jan 2009 23:02:41 -0700 Subject: [Hipsec-rg] =?utf-8?b?562U5aSNOiAgSGllcmFyY2hpY2FsIEhJVHM=?= In-Reply-To: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> Message-ID: <49717481.5030205@googlemail.com> Sheng Jiang wrote: >>>>>> I.e. when I change my network provider I will have to change the "HIP >>>>>> management domain" part in HIT? >> Sheng, thank you for such a long explanation, but I meant the following >> example. >> >> A customer does not want to pay anymore to Provider_A, whose management >> tag she has in her HHIT, but Provider_A does the mapping/etc service for >> her HHIT. So the customer will have to change her identifier (HHIT) in >> this case, right? >> >> I just do not see the reasons to have a new hierarchical space of >> identifiers. We already have the Internet address space, domain names, SSL >> certificates and so on. Of course, I might be wrong. > > Yes, we have so many hierarchical identifiers already. They are hierarchical > for reasons: aggregative, even more important for management purpose. This > is particularly important for host identity. Will any country allow entrance > of a man whose identity card is issued by himself only? Will BT give > services access to a host/device that has its own arbitrary identity? The > purpose of an identity is to identify itself, the most important, its > belonging. Our proposal embeds this belonging information into HIT, make the > HIT meaningful. The receiver or network management plane can easily validate > it. Hello Sheng, If my identifier is bound with one entity in the hierarchy, then I'm wondering what would be the advantage of using HHIT over traditional DNS names? --julien From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Sat, 17 Jan 2009 00:42:19 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> <49717246.2060004@laposte.net> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> Message-ID: Hi! On Sat, 17 Jan 2009, Sheng Jiang wrote: > As I explained earlier, a self-issued identity means little. Will any > country allow entrance of a man whose identity card is issued by himself > only? I think we should distinguish authorization (deciding whether to grant access) and authentication (verifying identity). -- Regards, Oleg. From: shengjiang at huawei.com (Sheng Jiang) Date: Sat, 17 Jan 2009 06:15:42 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogICBIaWVyYXJjaGljYWwgSElUcw==?= In-Reply-To: <49717246.2060004@laposte.net> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> <49717246.2060004@laposte.net> Message-ID: <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> > This is exactly the point; If a HHIT has the limitation that: > > - it is bound with one entity in the hierarchy compared to a plain HIT > (like a DNS name is) > > - is not human readable compared to a DNS name (like a HIT is) > > Then why should I use a HHIT as a host identifier? I'm getting all of > the disadvantages of HIT (not readable) or DNS name (bound to an entity > in the hierarchy) but none of their respective advantages, i.e., not > being bound to an entity, or being readble... I don't think bound to an entity in the hierarchy is a disadvantage at all. As I explained earlier, a self-issued identity means little. Will any country allow entrance of a man whose identity card is issued by himself only? Will BT give services access to a host/device that has its own arbitrary identity? With hierarchy, the identifier can actually have real meaning. If you are considering privacy issues, yes, we don't want the hierarchy information to be learned by receivers. Then our proposed HHIT architecture is also compatible with the flat-structured HIT architecture. By using the HHIT, we get a self-certified identity, itself and its belonging (hierarchy) can be easily verified by receivers. Cheers, Sheng From: shengjiang at huawei.com (Sheng Jiang) Date: Sat, 17 Jan 2009 05:20:08 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogILTwuLQ6ICBIaWVyYXJjaGljYWwgSElU?= =?gb2312?b?cw==?= In-Reply-To: <49715DE2.9010603@laposte.net> References: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <49715DE2.9010603@laposte.net> Message-ID: > Sheng Jiang wrote: > >>>>>> I.e. when I change my network provider I will have to change the "HIP > >>>>>> management domain" part in HIT? > >> Sheng, thank you for such a long explanation, but I meant the following > >> example. > >> > >> A customer does not want to pay anymore to Provider_A, whose management > >> tag she has in her HHIT, but Provider_A does the mapping/etc service for > >> her HHIT. So the customer will have to change her identifier (HHIT) in > >> this case, right? > >> > >> I just do not see the reasons to have a new hierarchical space of > >> identifiers. We already have the Internet address space, domain names, SSL > >> certificates and so on. Of course, I might be wrong. > > > > Yes, we have so many hierarchical identifiers already. They are hierarchical > > for reasons: aggregative, even more important for management purpose. This > > is particularly important for host identity. Will any country allow entrance > > of a man whose identity card is issued by himself only? Will BT give > > services access to a host/device that has its own arbitrary identity? The > > purpose of an identity is to identify itself, the most important, its > > belonging. Our proposal embeds this belonging information into HIT, make the > > HIT meaningful. The receiver or network management plane can easily validate > > it. > > Hello Sheng, > > If my identifier is bound with one entity in the hierarchy, then I'm > wondering what would be the advantage of using HHIT over traditional DNS > names? Good question, Julien. However, why do we have to using HHIT over DNS? For my understanding, because flat-structure HIT is lack of hierarchy, the best way to use it is with hierarchical domain name system. It is different for HHIT case. The Hierarchical HIT can be used alone. With its HIP management tag, a HHIT can have most of meaning of a domain name only except that it is non-human-readable. It can be mapped to locator directly. Regards, Sheng From: shengjiang at huawei.com (Sheng Jiang) Date: Fri, 16 Jan 2009 22:42:54 +0800 Subject: [Hipsec-rg] =?gb2312?b?tPC4tDogIEhpZXJhcmNoaWNhbCBISVRz?= In-Reply-To: References: Message-ID: <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> > >>>> I.e. when I change my network provider I will have to change the "HIP > >>>> management domain" part in HIT? > > Sheng, thank you for such a long explanation, but I meant the following > example. > > A customer does not want to pay anymore to Provider_A, whose management > tag she has in her HHIT, but Provider_A does the mapping/etc service for > her HHIT. So the customer will have to change her identifier (HHIT) in > this case, right? > > I just do not see the reasons to have a new hierarchical space of > identifiers. We already have the Internet address space, domain names, SSL > certificates and so on. Of course, I might be wrong. Yes, we have so many hierarchical identifiers already. They are hierarchical for reasons: aggregative, even more important for management purpose. This is particularly important for host identity. Will any country allow entrance of a man whose identity card is issued by himself only? Will BT give services access to a host/device that has its own arbitrary identity? The purpose of an identity is to identify itself, the most important, its belonging. Our proposal embeds this belonging information into HIT, make the HIT meaningful. The receiver or network management plane can easily validate it. Regards, Sheng From: xuxh at huawei.com (Xu Xiaohu) Date: Fri, 16 Jan 2009 10:03:40 +0800 Subject: [Hipsec-rg] Hierarchical HITs Message-ID: <000d01c9777e$a74bb0f0$670c6f0a@china.huawei.com> by the way, the idea of the hierarchical and cryptographic host ID in HRA is originated from some discussion with Pekka in the following thread: http://www.ops.ietf.org/lists/rrg/2007/msg00419.html For your information. Any comment welcomed. Xiaohu > -----????----- > ???: Xu Xiaohu [mailto:xuxh at huawei.com] > ????: 2009?1?16? 9:29 > ???: 'hipsec-rg at listserv.cybertrust.com' > ??: Re: [Hipsec-rg] Hierarchical HITs > > Hi all, > > The following is my paper about HRA (Hierarchical Routing > Architecture), which gives details about the defination of > the hierarchical ID (Borrowing some ideas from CGA)and > hierarchical locator , besides, how to use them to support > mobility and multihoming are also mentioned. > > Xiaohu Xu and Dayong Guo, ?Hierarchical Routing > Architecture,? Proc. 4th Euro-NGI Conference on Next > Generation Internetworks, Krakow, Poland, 28-30 April 2008, 7 > pp., http://www.cse.wustl.edu/~jain/papers/hra.htm > > There is also a ppt about RANGI (New name of HRA with some > update) which was presented on IETF73 RRG session, see > http://www.cse.wustl.edu/~jain/ietf/rangi.htm > > Xiaohu > > > > > > From: xuxh at huawei.com (Xu Xiaohu) Date: Fri, 16 Jan 2009 09:28:40 +0800 Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: <496F2ACB.4010703@helsinki.fi> Message-ID: <000b01c97779$c3689910$670c6f0a@china.huawei.com> Hi all, The following is my paper about HRA (Hierarchical Routing Architecture), which gives details about the defination of the hierarchical ID (Borrowing some ideas from CGA)and hierarchical locator , besides, how to use them to support mobility and multihoming are also mentioned. Xiaohu Xu and Dayong Guo, "Hierarchical Routing Architecture," Proc. 4th Euro-NGI Conference on Next Generation Internetworks, Krakow, Poland, 28-30 April 2008, 7 pp., http://www.cse.wustl.edu/~jain/papers/hra.htm There is also a ppt about RANGI (New name of HRA with some update) which was presented on IETF73 RRG session, see http://www.cse.wustl.edu/~jain/ietf/rangi.htm Xiaohu From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Fri, 16 Jan 2009 00:48:49 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: References: Message-ID: Hi! On Fri, 16 Jan 2009, JiangSheng 66104 wrote: >>>> I.e. when I change my network provider I will have to change the "HIP >>>> management domain" part in HIT? Sheng, thank you for such a long explanation, but I meant the following example. A customer does not want to pay anymore to Provider_A, whose management tag she has in her HHIT, but Provider_A does the mapping/etc service for her HHIT. So the customer will have to change her identifier (HHIT) in this case, right? I just do not see the reasons to have a new hierarchical space of identifiers. We already have the Internet address space, domain names, SSL certificates and so on. Of course, I might be wrong. -- Regards, Oleg. From: shengjiang at huawei.com (JiangSheng 66104) Date: Fri, 16 Jan 2009 05:27:35 +0800 Subject: [Hipsec-rg] Hierarchical HITs (Was: reverse DNS lookups of HITs) Message-ID: > 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 From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Thu, 15 Jan 2009 19:58:29 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs In-Reply-To: References: Message-ID: Hi! On Thu, 15 Jan 2009, JiangSheng 66104 wrote: > 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. So this will bind me to one provider forever? > 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. Or just use mobile IP for this purpose? >> "For each single looking up operation, one may search through most of >> the database, on average, O(number of total global HITs)." >> >> Did you mean O(log2(number of HITs)) time, which makes max O(100)? > > I actaully refer to the worst senarios, assuming the HIT is stored > disorderly in the data base. Why is it the worst one? What if I use another bad implementation and get O(2^(number of HITs))? P.S. [my basic degree is in math] The number of HITs is finite, therefore O(number of total global HITs) equals to O(1) -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Thu, 15 Jan 2009 08:49:05 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D07B0BC7C@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BCA1@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: JiangSheng 66104 [mailto:shengjiang at huawei.com] > Sent: Thursday, January 15, 2009 3:05 AM > To: Henderson, Thomas R > Cc: oleg.ponomarev at hiit.fi; > hipsec-rg at listserv.cybertrust.com; brian at cs.auckland.ac.nz; > shengjiang at huawei.com > Subject: Re: RE: [Hipsec-rg] reverse DNS lookups of HITs > > > Regarding your proposal: > > > > For index and resolution purposes, HITs are aggregatable with > > management domain tags of arbitrary bit-length, similar to IPv4 > > addresses under Classless Inter-Domain Routing [RFC4632]. > > ... > > The most important security property of HIT is that it is self- > > certifying (i.e., given a HIT, it is computationally hard to > > find a > > Host Identity key that matches the HIT). Although this document > > limits the hash output to be 94-bit long, it does not affect the > > self > > certifying security property. > > > > It seems to me that this self-certifying property is lost if one > > prepends an unsecured management domain tag. There is nothing > > stoppinga malicious node from using management domain tags of its > > choosing to > > evade ACLs that are based on management domain tags. > > You are right here. > > However, as it is a ongoing proposal, we are planning to > improve this in the future version, by including management > domain tag as a part of input for hash algorthim. This will > bind management domain tag with other security properties, > like what CGA does. Hence, the ACL that are based on > managment domain tags can verify a HHIT (for example, using > trust anchor, etc.) without recording every HIT in its list. > I'm still not convinced about basing ACLs on management domain tags directly. You still need some kind of authorization from the trust anchor to use the management tag. This is likely done with certificates. But in that case, you are free to use whatever name in the certificate as the name in the ACL. For example, let's say you are a middlebox that wants to enforce that only HITs authorized by example.com can access a service. If the HIP base exchange contains a certificate from a suitable trust anchor, one can make the ACLs based on, for example, DNS names with the suffix "example.com". This name can be in the certificate. And then, in policy-enforcement filter, once a session is authenticated, a bypass for the SPIs and HITs involved can be put into the middlebox. If a management domain tag is used instead, I'm not sure you can short cut any of the above steps to authenticate the use of the tag. So, it seems like the proposed HIP Certificate extensions provide a more flexible name space for ACLs. Rather, I see value in having a so-called Type 2 HIT (see old HIP drafts for this terminology) primarily for the use case that Oleg originally raised, to facilitate reverse lookups, but with some scaling and allowance for multiple name service providers to exist. For instance, if we were able to get a reasonably sized prefix allocated from IPv6 space (such as what ULAs received), we could use ~20 to 24 bits for this prefix and ~96 to 100 bits for hash. The 24 bits could probably be divided into something like 8 bits private use and 16 bits public use, and "HIP name service providers" could register for a value in the public bits. Tom From: samu.varjonen at helsinki.fi (Varjonen Samu) Date: Thu, 15 Jan 2009 14:23:39 +0200 Subject: [Hipsec-rg] Hierarchical HITs (Was: reverse DNS lookups of HITs) In-Reply-To: References: Message-ID: <496F2ACB.4010703@helsinki.fi> 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? BR, Samu >> And in >> >> "For each single looking up operation, one may search through most >> of the >> database, on average, O(number of total global HITs)." >> >> Did you mean O(log2(number of HITs)) time, which makes max O(100)? > > I actaully refer to the worst senarios, assuming the HIT is stored disorderly in the data base. On one side, database can store HIT in order and use lookup algorthim to improve looking up effeciency. However, on another side, without proper mechanisms being applied during the HIT generation, there may be many disorder factors, such as HIT databases should be under different management giving the nature of the different ISP, flat HITs may be stored disorderly along a distributed database, etc. > > Best regards, > > Sheng > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg at listserv.cybertrust.com > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg > From: shengjiang at huawei.com (JiangSheng 66104) Date: Thu, 15 Jan 2009 19:40:19 +0800 Subject: [Hipsec-rg] Hierarchical HITs (Was: reverse DNS lookups of HITs) In-Reply-To: References: Message-ID: > > (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. > And in > > "For each single looking up operation, one may search through most > of the > database, on average, O(number of total global HITs)." > > Did you mean O(log2(number of HITs)) time, which makes max O(100)? I actaully refer to the worst senarios, assuming the HIT is stored disorderly in the data base. On one side, database can store HIT in order and use lookup algorthim to improve looking up effeciency. However, on another side, without proper mechanisms being applied during the HIT generation, there may be many disorder factors, such as HIT databases should be under different management giving the nature of the different ISP, flat HITs may be stored disorderly along a distributed database, etc. Best regards, Sheng From: shengjiang at huawei.com (JiangSheng 66104) Date: Thu, 15 Jan 2009 19:05:10 +0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC7C@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BC7C@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: > Regarding your proposal: > > For index and resolution purposes, HITs are aggregatable with > management domain tags of arbitrary bit-length, similar to IPv4 > addresses under Classless Inter-Domain Routing [RFC4632]. > ... > The most important security property of HIT is that it is self- > certifying (i.e., given a HIT, it is computationally hard to > find a > Host Identity key that matches the HIT). Although this document > limits the hash output to be 94-bit long, it does not affect the > self > certifying security property. > > It seems to me that this self-certifying property is lost if one > prepends an unsecured management domain tag. There is nothing > stoppinga malicious node from using management domain tags of its > choosing to > evade ACLs that are based on management domain tags. You are right here. However, as it is a ongoing proposal, we are planning to improve this in the future version, by including management domain tag as a part of input for hash algorthim. This will bind management domain tag with other security properties, like what CGA does. Hence, the ACL that are based on managment domain tags can verify a HHIT (for example, using trust anchor, etc.) without recording every HIT in its list. Best regards, Sheng From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Tue, 13 Jan 2009 08:15:11 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC7D@XCH-NW-5V1.nw.nos.boeing.com> > > > >> I think we (myself included) should all go read the FARA > paper again: > >> > >> FARA: Reorganizing the Addressing Architecture ( the first of 3 > >> papers at http://www.isi.edu/newarch/fara.html ) > > > > I guess it would take some time to deploy a solution which > requires > > new network architecture, when we need something to use now. > > Those papers represent some serious research into the > implications of > the architecture. We've implemented something with HIP, but > it seems > there is disagreement as to the architecture... if reverse > lookups are > even desirable is an architectural question, after all. > Personally, I > think there is no need for reverse lookups. > I do not think there is disagreement with the architecture, but perhaps the service model. I think there is no need for reverse lookups if entities involved (including third party middleboxes) are handling HITs directly, or if the HIT to domain name mapping is preconfigured, or if the systems use other name resolution services than DNS. However, I suspect that will not always be the case. Note that ssh implementations sometimes performs reverse lookups for host authentication. What do you see as being different for HIP? - Tom From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Tue, 13 Jan 2009 07:22:58 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC7C@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: JiangSheng 66104 [mailto:shengjiang at huawei.com] > Sent: Tuesday, January 13, 2009 2:22 AM > To: Henderson, Thomas R; oleg.ponomarev at hiit.fi > Cc: hipsec-rg at listserv.cybertrust.com; > brian at cs.auckland.ac.nz; shengjiang at huawei.com > Subject: Re: [Hipsec-rg] reverse DNS lookups of HITs > > > > > 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? > > This is exactly where we need hierarchical HIT for. (See > http://tools.ietf.org/id/draft-jiang-hiprg-hhit-arch-01.txt.) > The aggregation of Hierarchical HIT proposal can help to > organize HITs in the large scale deployment and improve > looking-up efficiency in either mapping system (such as DNS, > or DHT, etc.) or ACL. This proposal is also compatible with > the flat-structured HIT architecture, which can meet the > requirement of privacy. Regarding your proposal: For index and resolution purposes, HITs are aggregatable with management domain tags of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing [RFC4632]. ... The most important security property of HIT is that it is self- certifying (i.e., given a HIT, it is computationally hard to find a Host Identity key that matches the HIT). Although this document limits the hash output to be 94-bit long, it does not affect the self certifying security property. It seems to me that this self-certifying property is lost if one prepends an unsecured management domain tag. There is nothing stopping a malicious node from using management domain tags of its choosing to evade ACLs that are based on management domain tags. - Tom From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 13 Jan 2009 17:19:45 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <496CAC75.8070304@hiit.fi> References: <496CAC75.8070304@hiit.fi> Message-ID: Miika, no, we do not care about the IP addresses in this case. The hosts send their FQDNs (available to the HIP daemon) in I2/R2 packets and those FQDNs are returned by the resolver for the HITs. It sounds good in theory, but is painful to implement, IMHO. > (assuming I understood you correctly), there may be no HIP associations > available that contain HIT-to-IP mapping information. So we can't always rely > on that and I am not sure if it is a good idea to store the mappings > permanently on disk available to the HIP daemon. -- Regards, Oleg. From: miika.komu at hiit.fi (Miika Komu) Date: Tue, 13 Jan 2009 17:00:05 +0200 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: <496CAC75.8070304@hiit.fi> Andrew McGregor wrote: Hi, > On 13/01/2009, at 11:21 PM, Oleg Ponomarev wrote: > >> Hi! On Tue, 13 Jan 2009, Andrew McGregor wrote: >> >>>> I might have a mistaken view, but usually we only check the presence >>>> of the key in the list of authorized/known keys, so we do not need >>>> such a lookup. >>> >>> I think that was exactly the point... we don't need such lookups. >> >> ... for the SSH keys, when we have complete list of them in a file. >> This may be not the case for millions of host identities. >> >>> Personally, I think there is no need for reverse lookups. >> >> How many hosts use HIP in your network? I implemented this because I >> was irritated by [trimmed] hex sequences in the netstat output (for >> example). I prefer understandable names and also had reverse zones >> (locally) for RFC1918 addresses in another network with thousands of >> hosts which nobody could remember by heart. > > Yes, that is a point. However, it's also an implementation > limitation... if, for instance, your HIP implementation knows about > FQDNs sent by the other end, or certificate fields, it can arrange that > your reverse resolver library will say something sensible about the > host. The resolver doesn't HAVE to use DNS to supply that information, > and given that HIP is a security binding protocol anyway, it makes more > sense to get this information from the current state of the bindings, > rather than by another insecure protocol outside of the current security > binding state. (assuming I understood you correctly), there may be no HIP associations available that contain HIT-to-IP mapping information. So we can't always rely on that and I am not sure if it is a good idea to store the mappings permanently on disk available to the HIP daemon. From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 13 Jan 2009 15:39:45 +0200 (EET) Subject: [Hipsec-rg] Hierarchical HITs (Was: reverse DNS lookups of HITs) In-Reply-To: References: Message-ID: Hi! On Tue, 13 Jan 2009, 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? And in "For each single looking up operation, one may search through most of the database, on average, O(number of total global HITs)." Did you mean O(log2(number of HITs)) time, which makes max O(100)? -- Regards, Oleg. From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 13 Jan 2009 13:11:50 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: On Tue, 13 Jan 2009, Andrew McGregor wrote: > your HIP implementation knows about FQDNs sent by the other end Oh, I thought you do not like reverse DNS for HITs in general. Yes, I mentioned it as another solution (https://listserv.cybertrust.com/ pipermail/hipsec-rg/2009-January/000567.html) But how much effort will it take to modify all resolver libraries? It would be much more difficult to debug. Deployment? >> I would like to grant access to the clients from example-company.com >> regardless of their current locators. If there is no forward confirmed >> reverse DNS, what should I do now? > > Certificates for this one. Ok, how should I configure my nntp-server (whatever legacy service) to demand certificates from the clients? How much tech support resources I will spend to change settings of their nntp-readers (whatever legacy clients). Will they keep using my service? I do not need high-grade security in this case and do not want to waste resources. -- Regards, Oleg. From: andrew at indranet.co.nz (Andrew McGregor) Date: Tue, 13 Jan 2009 23:37:46 +1300 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: On 13/01/2009, at 11:21 PM, Oleg Ponomarev wrote: > Hi! On Tue, 13 Jan 2009, Andrew McGregor wrote: > >>> I might have a mistaken view, but usually we only check the >>> presence of the key in the list of authorized/known keys, so we do >>> not need such a lookup. >> >> I think that was exactly the point... we don't need such lookups. > > ... for the SSH keys, when we have complete list of them in a file. > This may be not the case for millions of host identities. > >> Personally, I think there is no need for reverse lookups. > > How many hosts use HIP in your network? I implemented this because I > was irritated by [trimmed] hex sequences in the netstat output (for > example). I prefer understandable names and also had reverse zones > (locally) for RFC1918 addresses in another network with thousands of > hosts which nobody could remember by heart. Yes, that is a point. However, it's also an implementation limitation... if, for instance, your HIP implementation knows about FQDNs sent by the other end, or certificate fields, it can arrange that your reverse resolver library will say something sensible about the host. The resolver doesn't HAVE to use DNS to supply that information, and given that HIP is a security binding protocol anyway, it makes more sense to get this information from the current state of the bindings, rather than by another insecure protocol outside of the current security binding state. > > > I would like to grant access to the clients from example-company.com > regardless of their current locators. If there is no forward > confirmed reverse DNS, what should I do now? Certificates for this one. > > > One could use reverse DNS for the reputation purposes. But you can't trust that for a security process. Andrew From: shengjiang at huawei.com (JiangSheng 66104) Date: Tue, 13 Jan 2009 18:21:43 +0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs Message-ID: > > > 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? This is exactly where we need hierarchical HIT for. (See http://tools.ietf.org/id/draft-jiang-hiprg-hhit-arch-01.txt.) The aggregation of Hierarchical HIT proposal can help to organize HITs in the large scale deployment and improve looking-up efficiency in either mapping system (such as DNS, or DHT, etc.) or ACL. This proposal is also compatible with the flat-structured HIT architecture, which can meet the requirement of privacy. Regards, Sheng Jiang From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 13 Jan 2009 12:21:06 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: Hi! On Tue, 13 Jan 2009, Andrew McGregor wrote: >> I might have a mistaken view, but usually we only check the presence of the >> key in the list of authorized/known keys, so we do not need such a lookup. > > I think that was exactly the point... we don't need such lookups. ... for the SSH keys, when we have complete list of them in a file. This may be not the case for millions of host identities. > Personally, I think there is no need for reverse lookups. How many hosts use HIP in your network? I implemented this because I was irritated by [trimmed] hex sequences in the netstat output (for example). I prefer understandable names and also had reverse zones (locally) for RFC1918 addresses in another network with thousands of hosts which nobody could remember by heart. I would like to grant access to the clients from example-company.com regardless of their current locators. If there is no forward confirmed reverse DNS, what should I do now? One could use reverse DNS for the reputation purposes. -- Regards, Oleg. From: andrew at indranet.co.nz (Andrew McGregor) Date: Tue, 13 Jan 2009 22:38:19 +1300 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: On 13/01/2009, at 9:27 PM, Oleg Ponomarev wrote: > Hello! On Mon, 12 Jan 2009, Tim Shepard wrote: > >> I view HITs as very similar to SSH host keys. And just like we >> have no need for a network-wide way of looking up an ssh host key >> to find out what host it corresponds to, perhaps we can do without >> any network-wide way of looking up a HIT (or HI). > > I might have a mistaken view, but usually we only check the presence > of the key in the list of authorized/known keys, so we do not need > such a lookup. I think that was exactly the point... we don't need such lookups. > > > >> I think we (myself included) should all go read the FARA paper again: >> >> FARA: Reorganizing the Addressing Architecture ( the first of 3 >> papers at http://www.isi.edu/newarch/fara.html ) > > I guess it would take some time to deploy a solution which requires > new network architecture, when we need something to use now. Those papers represent some serious research into the implications of the architecture. We've implemented something with HIP, but it seems there is disagreement as to the architecture... if reverse lookups are even desirable is an architectural question, after all. Personally, I think there is no need for reverse lookups. Andrew From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Tue, 13 Jan 2009 10:27:16 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Message-ID: Hello! On Mon, 12 Jan 2009, Tim Shepard wrote: I hope it is ok to continue the thread in this mailing list. >>> Or, if that turns out to be a bad idea, what are the practical >>> alternatives that allow someone to write domain-name-based ACLs? One alternative I can imagine is to record the hostname provided by the peer during the HIP base exchange and resolve HITs of known peers to those hostnames. This would not require any centralized infrastructure, but would have lots of drawbacks. > I view HITs as very similar to SSH host keys. And just like we have no > need for a network-wide way of looking up an ssh host key to find out > what host it corresponds to, perhaps we can do without any network-wide > way of looking up a HIT (or HI). I might have a mistaken view, but usually we only check the presence of the key in the list of authorized/known keys, so we do not need such a lookup. > I think we (myself included) should all go read the FARA paper again: > > FARA: Reorganizing the Addressing Architecture ( the first of 3 papers > at http://www.isi.edu/newarch/fara.html ) I guess it would take some time to deploy a solution which requires new network architecture, when we need something to use now. -- Regards, Oleg. From: xuxh at huawei.com (Xu Xiaohu) Date: Tue, 13 Jan 2009 11:35:01 +0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC78@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <000a01c9752f$eaddffe0$670c6f0a@china.huawei.com> [Note: This email is also copied to RRG, I believe some RRGer will also have interest on it. If not, sorry for disturbing you.] > > 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? Hi Tom, That's why I suggested the flat HIT should be modified to have some structure during the IETF72 meeting. The thread is as follows: https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-July/000509.html Xiaohu From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 12 Jan 2009 14:46:54 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: Your message of Mon, 12 Jan 2009 23:41:38 +0200. Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC79@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: Tim Shepard [mailto:shep at alum.mit.edu] > Sent: Monday, January 12, 2009 2:09 PM > To: Oleg Ponomarev > Cc: Henderson, Thomas R; hipsec-rg at listserv.cybertrust.com > Subject: Re: [Hipsec-rg] reverse DNS lookups of HITs > > > > > > Or, if that turns out to be a bad idea, what are the practical > > > alternatives that allow someone to write domain-name-based ACLs? > > > > > > I think it would be great to gather more input on these types of > > > deployment questions. > > > > Actually I wonder how could I use HITs without reverse > domains, I don't > > want to keep random hex sequences in the memory, but it is > probably just > > my feeling. > > > I view HITs as very similar to SSH host keys. I agree with that. > And just like we have > no need for a network-wide way of looking up an ssh host key to find > out what host it corresponds to, perhaps we can do without any > network-wide way of looking up a HIT (or HI). > I think that for small deployments, this will be adequate. However, for others, particularly those that involve middleboxes or policy-enforcing endboxes that inspect traffic and apply ACLs, I doubt it will be sufficient to work with keys directly. Also, my personal experience with ssh is that it involves a lot of leap-of-faith situations. - Tom From: shep at alum.mit.edu (Tim Shepard) Date: Mon, 12 Jan 2009 17:09:09 -0500 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: Your message of Mon, 12 Jan 2009 23:41:38 +0200. Message-ID: > > Or, if that turns out to be a bad idea, what are the practical > > alternatives that allow someone to write domain-name-based ACLs? > > > > I think it would be great to gather more input on these types of > > deployment questions. > > Actually I wonder how could I use HITs without reverse domains, I don't > want to keep random hex sequences in the memory, but it is probably just > my feeling. I view HITs as very similar to SSH host keys. And just like we have no need for a network-wide way of looking up an ssh host key to find out what host it corresponds to, perhaps we can do without any network-wide way of looking up a HIT (or HI). I think we (myself included) should all go read the FARA paper again: FARA: Reorganizing the Addressing Architecture ( the first of 3 papers at http://www.isi.edu/newarch/fara.html ) -Tim Shepard shep at alum.mit.edu From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Mon, 12 Jan 2009 23:41:38 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC78@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC76@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC78@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: Hi! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: >> 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, Sure! I would like to get more precise/supported estimations and could do some experiments/benchmarks with the conventional software (which is not optimal for this usage pattern). > and how will the deployment incentives work? What are the incentives to host the root-servers (e.g. f.root-servers.net at 46 and j.root-servers.net at 52 sites)? Internet stability? Hopefully the same will work for HIP when deployed. > Or, if that turns out to be a bad idea, what are the practical > alternatives that allow someone to write domain-name-based ACLs? > > I think it would be great to gather more input on these types of > deployment questions. Actually I wonder how could I use HITs without reverse domains, I don't want to keep random hex sequences in the memory, but it is probably just my feeling. -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 12 Jan 2009 12:58:43 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC76@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC78@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: Oleg Ponomarev [mailto:oleg.ponomarev at hiit.fi] > Sent: Monday, January 12, 2009 12:39 PM > To: Henderson, Thomas R > Cc: hipsec-rg at listserv.cybertrust.com > Subject: Re: [Hipsec-rg] reverse DNS lookups of HITs > > Hi! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: > > > Yes, but how do you delegate below that top level? > > > > If I am a HIP user, and I generate a key for myself, how do > I register > > it with A.OUR-SERVERS.NET.? Do they have an open policy > and let just > > anyone in the Internet add a record for themselves? > > I would say yes. If there is a DoS attack, give puzzles. > > > 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? I think it would be great to gather more input on these types of deployment questions. - Tom From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Mon, 12 Jan 2009 22:38:32 +0200 (EET) Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC76@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC76@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: Hi! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: > Yes, but how do you delegate below that top level? > > If I am a HIP user, and I generate a key for myself, how do I register > it with A.OUR-SERVERS.NET.? Do they have an open policy and let just > anyone in the Internet add a record for themselves? I would say yes. If there is a DoS attack, give puzzles. > 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 :) -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 12 Jan 2009 11:50:49 -0800 Subject: [Hipsec-rg] reverse DNS lookups of HITs (was RE: meeting minutes posted) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC76@XCH-NW-5V1.nw.nos.boeing.com> (changing the subject line) > -----Original Message----- > From: Oleg Ponomarev [mailto:oleg.ponomarev at hiit.fi] > Sent: Monday, January 12, 2009 11:38 AM > To: Henderson, Thomas R > Cc: hipsec-rg at listserv.cybertrust.com > Subject: RE: [Hipsec-rg] meeting minutes posted > > Greetings! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: > > >> For example, only 2001:1e:574e:2505:264a:b360:d8cc:1d75 is > allowed to > >> modify > 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 PTRs > > > > Functionally, I see how that can work, but operationally, > do you propose > > that the five root servers of ip6.arpa implement and > maintain this? Or, > > presuming that there is a HIP-specific allocation in the > future, that > > there is a global root nameserver or set of nameservers for > this HIT > > space? > > The latter, i.e. get delegation for 1.0.0.1.0.0.2.IP6.ARPA > (or whatever): > 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS > A.OUR-SERVERS.NET. > 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS > B.OUR-SERVERS.NET. > 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS > C.OUR-SERVERS.NET. > > The ip6.arpa nameservers already get those queries when there is HIP > connection, they just reply with NXDOMAIN. Yes, but how do you delegate below that top level? If I am a HIP user, and I generate a key for myself, how do I register it with A.OUR-SERVERS.NET.? Do they have an open policy and let just anyone in the Internet add a record for themselves? 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. > > Why do we need reverse mapping for HITs in general? I would > prefer to see > symbolic domain in logs instead of hex addresses, or put > *.my-org.com to > some access list instead of comma-separated list of HITs and so on. > Yes, that would clearly be a nice feature. Tom From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Mon, 12 Jan 2009 21:38:24 +0200 (EET) Subject: [Hipsec-rg] meeting minutes posted In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: Greetings! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: >> For example, only 2001:1e:574e:2505:264a:b360:d8cc:1d75 is allowed to >> modify 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 PTRs > > Functionally, I see how that can work, but operationally, do you propose > that the five root servers of ip6.arpa implement and maintain this? Or, > presuming that there is a HIP-specific allocation in the future, that > there is a global root nameserver or set of nameservers for this HIT > space? The latter, i.e. get delegation for 1.0.0.1.0.0.2.IP6.ARPA (or whatever): 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS A.OUR-SERVERS.NET. 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS B.OUR-SERVERS.NET. 1.0.0.1.0.0.2.IP6.ARPA. 172800 IN NS C.OUR-SERVERS.NET. The ip6.arpa nameservers already get those queries when there is HIP connection, they just reply with NXDOMAIN. Why do we need reverse mapping for HITs in general? I would prefer to see symbolic domain in logs instead of hex addresses, or put *.my-org.com to some access list instead of comma-separated list of HITs and so on. -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 12 Jan 2009 08:52:38 -0800 Subject: [Hipsec-rg] meeting minutes posted In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC70@XCH-NW-5V1.nw.nos.boeing.com> > > > But how do you view that delegation might work in this space, using > > HITs? > > I implemented an access policy for BIND9 (small patch from > HIPL source > needed) that allows DNS updates to 1.0.0.1.0.0.2.ip6.arpa iff > they are > sent from HITs. So Host Identifiers itself are used as keys to > authenticate the updater. > > For example, only 2001:1e:574e:2505:264a:b360:d8cc:1d75 is allowed to > modify > 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 > PTRs Functionally, I see how that can work, but operationally, do you propose that the five root servers of ip6.arpa implement and maintain this? Or, presuming that there is a HIP-specific allocation in the future, that there is a global root nameserver or set of nameservers for this HIT space? Tom From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Mon, 12 Jan 2009 18:15:39 +0200 (EET) Subject: [Hipsec-rg] meeting minutes posted In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: Hi! On Mon, 12 Jan 2009, Henderson, Thomas R wrote: > There was some discussion of this about two years ago, when the HIP > drafts went through secdir review. See, for instance, this thread: Thanks for the refs! >> Actually it would be useful to have IPv6 address space >> reserved for HIP >> only, then we could have ip6.arpa pointers etc > > In some sense, we have some address space reserved in 2001:10::/28 > (RFC4843). Yes, but it is common for any types of ORCHID. Therefore if HIP is required to modify the ip6.arpa records, it may cause troubles. > But how do you view that delegation might work in this space, using > HITs? I implemented an access policy for BIND9 (small patch from HIPL source needed) that allows DNS updates to 1.0.0.1.0.0.2.ip6.arpa iff they are sent from HITs. So Host Identifiers itself are used as keys to authenticate the updater. For example, only 2001:1e:574e:2505:264a:b360:d8cc:1d75 is allowed to modify 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 PTRs /* aeris.hiit-nrg.net runs named with that patch */ -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 12 Jan 2009 08:00:16 -0800 Subject: [Hipsec-rg] meeting minutes posted In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC6B@XCH-NW-5V1.nw.nos.boeing.com> > -----Original Message----- > From: Oleg Ponomarev [mailto:oleg.ponomarev at hiit.fi] > Sent: Wednesday, January 07, 2009 6:58 AM > To: hipsec-rg at listserv.cybertrust.com > Subject: Re: [Hipsec-rg] meeting minutes posted > > Greetings! > > > BM: Bob is working on moving HIP onto the standards track. ADs are > > looking at the HIPWG charter to address RFC5201 IESG > concerns, and to > > advance BEET. The big concern in 5201 is crypto agility, > there are some > > issues there. There will be a call for proposals on > addressing crypto > > agility concerns without making the protocol too heavy. > Please look at > > those issues. > > SHA1 is used now as a hash function to get HITSs, but are > there any plans > to phase out its use in favor of the SHA-2 variants? I was > just wondering > what happens in case of a HIT collision, since the complexity of an > existing attack[1] is only 2**63. Oleg, There was some discussion of this about two years ago, when the HIP drafts went through secdir review. See, for instance, this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg01743.html and this: http://www.ietf.org/mail-archive/web/hipsec/current/msg01756.html To address these concerns, we agreed with the IESG to place a note in RFC5201 to state that this issue needs to be handled before HIP could be considered for standards track. But, to my knowledge, there hasn't been further work on this point since then. > > Actually it would be useful to have IPv6 address space > reserved for HIP > only, then we could have ip6.arpa pointers etc In some sense, we have some address space reserved in 2001:10::/28 (RFC4843). But how do you view that delegation might work in this space, using HITs? Tom From: miika.komu at hiit.fi (Miika Komu) Date: Mon, 12 Jan 2009 15:16:39 +0200 Subject: [Hipsec-rg] reverse DNS lookups of HITs In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BC79@XCH-NW-5V1.nw.nos.boeing.com> References: Your message of Mon, 12 Jan 2009 23:41:38 +0200. <77F357662F8BFA4CA7074B0410171B6D07B0BC79@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <496B42B7.1030107@hiit.fi> Henderson, Thomas R wrote: Hi, >> -----Original Message----- >> From: Tim Shepard [mailto:shep at alum.mit.edu] >> Sent: Monday, January 12, 2009 2:09 PM >> To: Oleg Ponomarev >> Cc: Henderson, Thomas R; hipsec-rg at listserv.cybertrust.com >> Subject: Re: [Hipsec-rg] reverse DNS lookups of HITs >> >> >> >>>> Or, if that turns out to be a bad idea, what are the practical >>>> alternatives that allow someone to write domain-name-based ACLs? >>>> >>>> I think it would be great to gather more input on these types of >>>> deployment questions. >>> Actually I wonder how could I use HITs without reverse >> domains, I don't >>> want to keep random hex sequences in the memory, but it is >> probably just >>> my feeling. >> >> I view HITs as very similar to SSH host keys. > > I agree with that. > >> And just like we have >> no need for a network-wide way of looking up an ssh host key to find >> out what host it corresponds to, perhaps we can do without any >> network-wide way of looking up a HIT (or HI). >> > > I think that for small deployments, this will be adequate. However, for > others, particularly those that involve middleboxes or policy-enforcing > endboxes that inspect traffic and apply ACLs, I doubt it will be > sufficient to work with keys directly. Also, my personal experience > with ssh is that it involves a lot of leap-of-faith situations. AFAIK, hip4inter.net supports opportunistic mode at the sockets layer (as well as OpenHIP?). HIPL support it with LD_PRELOAD and iptables. I just presented yesterday our experimentation on opportunistic mode: Miika Komu and Janne Lindqvist, Leap-of-Faith Security is Enough for IP Mobility, 6th Annual IEEE Consumer Communications & Networking Conference IEEE CCNC 2009, Las Vegas, Nevada, January 2009 I think we still need to have HI records in DNS and I believe the work Oleg has been doing is very valuable. From: oleg.ponomarev at hiit.fi (Oleg Ponomarev) Date: Wed, 7 Jan 2009 16:58:10 +0200 (EET) Subject: [Hipsec-rg] meeting minutes posted In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BBE5@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: Greetings! > BM: Bob is working on moving HIP onto the standards track. ADs are > looking at the HIPWG charter to address RFC5201 IESG concerns, and to > advance BEET. The big concern in 5201 is crypto agility, there are some > issues there. There will be a call for proposals on addressing crypto > agility concerns without making the protocol too heavy. Please look at > those issues. SHA1 is used now as a hash function to get HITSs, but are there any plans to phase out its use in favor of the SHA-2 variants? I was just wondering what happens in case of a HIT collision, since the complexity of an existing attack[1] is only 2**63. Actually it would be useful to have IPv6 address space reserved for HIP only, then we could have ip6.arpa pointers etc [1] http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html -- Regards, Oleg. From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon, 5 Jan 2009 08:04:13 -0800 Subject: [Hipsec-rg] FW: The Internet architecture - pointer to MIF (Multiple Interfaces)discussion Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BC17@XCH-NW-5V1.nw.nos.boeing.com> FYI ________________________________ From: Hui Deng [mailto:denghui02 at gmail.com] Sent: Monday, January 05, 2009 6:36 AM To: ietf at ietf.org; mif at ietf.org Cc: denghui at chinamobile.com Subject: The Internet architecture - pointer to MIF (Multiple Interfaces)discussion Hello,all We have setup an mailing list to discuss the host which would like to use multiple interfaces. several issues has been identified based on problem statement. http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement -00.txt Please be awared that it is different from multihoming (site with multiple interfaces). Please feel free to join our discussion over there, https://www.ietf.org/mailman/listinfo/mif thanks -Hui -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT2394624.txt URL: From: miika.komu at hiit.fi (Miika Komu) Date: Mon, 05 Jan 2009 18:04:11 +0200 Subject: [Hipsec-rg] [Fwd: hipl release 1.0.4] Message-ID: <49622F7B.2000909@hiit.fi> FYI, -------- Original Message -------- Subject: hipl release 1.0.4 Date: Mon, 05 Jan 2009 18:02:49 +0200 From: Miika Komu Reply-To: miika.komu at hiit.fi To: hipl-users at freelists.org, hipl-announce at freelists.org Hi folks, we have published HIP for Linux (HIPL) release 1.0.4 in the URL below: http://infrahip.hiit.fi/hipl/release/1.0.4/ The release includes binaries for Ubuntu, Fedora, CentOS and Maemo for Nokia Tablets. The binaries (and updates) can also be downloaded using apt and yum in few steps using the instructions below: http://infrahip.hiit.fi/index.php?index=download The release includes many improvements including a number of bug fixes and better support for infrastructure (DNS, Bamboo DHT, rendezvous). Please refer to release notes for further details. The main theme in the following release (1.0.5) is on fault-tolerant mobility management. Suggestions for improvements and bugs can be reported at: http://www.freelists.org/list/hipl-users From: miika.komu at hiit.fi (Miika Komu) Date: Fri, 02 Jan 2009 10:54:12 +0200 Subject: [Hipsec-rg] help to implement sip-hip combination ieee research paper In-Reply-To: <13259015.96241230871028470.JavaMail.root@durga.amrita.ac.in> References: <13259015.96241230871028470.JavaMail.root@durga.amrita.ac.in> Message-ID: <495DD634.7000107@hiit.fi> Sheena R wrote: Hi, there are three public HIP implementations: * www.openhip.org (windows, mac, linux) * hip4inter.net (freebsd) * hipl.infrahip.net (linux on normal PCs, tablets and openwrt) Basically all of them should be working transparently with java with either LSIs or HITs. HIPL has native API support for java. > Hi, > We are Bachelors students(B.Tech Information technology) working on implementing the ieee research paper-"A > Framework to combine the Session Initiation Protocol and the Host Identity > Protocol"----> > seeking help on implementing this using openhipand JAIN SIP > Is there a Java implementation of HIP available?? > > > ref : the ieee paper is available at the following link > > From: sheena_05it51 at students.amrita.ac.in (Sheena R) Date: Fri, 2 Jan 2009 10:07:08 +0530 (IST) Subject: [Hipsec-rg] help to implement sip-hip combination ieee research paper In-Reply-To: Message-ID: <13259015.96241230871028470.JavaMail.root@durga.amrita.ac.in> Hi, We are Bachelors students(B.Tech Information technology) working on implementing the ieee research paper-"A Framework to combine the Session Initiation Protocol and the Host Identity Protocol"----> seeking help on implementing this using openhipand JAIN SIP Is there a Java implementation of HIP available?? ref : the ieee paper is available at the following link http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4489030/4489031/04489564.pdf?temp=x