Subject: [Hipsec-rg] 答复: Key Revocation Issue
From: zhangdacheng at huawei.com (Zhang Dacheng)
Date: Sun, 01 Feb 2009 10:01:18 +0800

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

Hi:

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

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

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

This is just my humble personal opinion. 

Best wishes,

Dacheng Zhang

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

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Andrew McGregor kirjoitti:
> But you are just describing the internal workings of a certificate. So 
> why dos the HIP certificates work not suffice?
> 

Yes, simple certificate stating that this HI belongs to the signers 
domain, carried in CERT parameter, would suffice for the ACL purposes at 
least in my opinion.

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

-- 
BR,
Samu

"Programmer is an organism that changes caffeine into code"

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <xuxh at huawei.com> wrote:

> [please skip the previous email]
>
> Oleg.
>
> Does every host in HIP architecture need a FQDN? (btw, there  were  
> similar
> threads in RRG,see  http://www.ops.ietf.org/lists/rrg/2008/msg02050.html 
> )
>
> If the access control is based on HIT, the firewall maybe need to  
> maintain
> an ACL with a huge amount of flat HIT entries. If the access control  
> is
> based on domain name , it will need
> to do lookup to resolve each HIT to FQDN in order to determine the  
> domain
> name.  Both of them mean a huge burden on firewalls. Besides, the  
> latter
> will aslo introduce a DDoS attack risk.
>
> With hierarchical HIT(Adminstrative Domain(AD) ID+ Hash (public key 
> +AD ID)),
> the firewall can simply do access control based on the AD ID.
>
> Xiaohu
>
>> -----????-----
>> ???: Xu Xiaohu [mailto:xuxh at huawei.com]
>> ????: 2009?1?22? 11:19
>> ???: 'Oleg Ponomarev'; 'Zhang Dacheng'
>> ??: 'hipsec-rg at listserv.cybertrust.com'
>> ??: re: [Hipsec-rg] Hierarchical HITs
>>
>>
>>> Once again, we already have hierarchical identities (e.g.
>>> domain names) and I do not see the reasons to introduce yet another
>>> hierarchical space.
>>> Of course, this is just my opinion.
>>
>> Oleg.
>>
>> Does every host in HIP architecture need a FQDN? (btw, there
>> were similar threads n RRG,see
>> http://www.ops.ietf.org/lists/rrg/2008/msg02050.html)
>>
>> If the access control is based on HIT, the firewall needs to
>> maintain an ACL with a huge amount of flat HIT entries. Both
>> of them mean a huge burden on firewalls. Besides, the former
>> will aslo introduce a DDoS attack risk., when a firewall
>> enforces access control based on domain name , it will need
>> to do lookup to resolve each HIT to FQDN in order to
>> determine its domain name.
>>
>> With hierarchical HIT (Adminstrative Domain(AD) ID+ Hash
>> (public key+AD ID)), the firewall can simply do access
>> control based on the AD ID.
>>
>> Xiaohu
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: xuxh at huawei.com (Xu Xiaohu)
Date: Thu, 22 Jan 2009 11:27:29 +0800
Subject: [Hipsec-rg] Hierarchical HITs
Message-ID: <[email-masked]>

[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: <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

[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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <oleg.ponomarev at hiit.fi>
Date: Tuesday, January 20, 2009 11:15 pm
Subject: Re: [Hipsec-rg] Hierarchical HITs
To: Zhang Dacheng <zhangdacheng at huawei.com>
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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]> <D8E864423971478CBA743BECAE60EB4E@JiangXiong> <[email-masked]> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong> <[email-masked]>
Message-ID: <[email-masked]>

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 <julien.laganier.ietf at googlemail.com>
Date: Saturday, January 17, 2009 6:42 am
Subject: Re: [Hipsec-rg]  Hierarchical HITs
To: Sheng Jiang <shengjiang at huawei.com>
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: <[email-masked]> <[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]> <D8E864423971478CBA743BECAE60EB4E@JiangXiong> <[email-masked]> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong>
Message-ID: <[email-masked]>

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: <D8E864423971478CBA743BECAE60EB4E@JiangXiong>
References: <[email-masked]>	<[email-masked]>	<1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong>	<[email-masked]> <D8E864423971478CBA743BECAE60EB4E@JiangXiong>
Message-ID: <[email-masked]>

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: <[email-masked]>	<[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong>
Message-ID: <[email-masked]>

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: <[email-masked]> <[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]> <D8E864423971478CBA743BECAE60EB4E@JiangXiong> <[email-masked]> <5727D3BB8C774649A5AC98E897EABB1C@JiangXiong>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]> <D8E864423971478CBA743BECAE60EB4E@JiangXiong> <[email-masked]>
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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1CC9CAD8FB744ADA82C9A6F4C2AC8B03@JiangXiong> <[email-masked]>
Message-ID: <D8E864423971478CBA743BECAE60EB4E@JiangXiong>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
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: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > (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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >
> >> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> -----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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

> > > 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

[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: <[email-masked]>
References: Your message of Mon, 12 Jan 2009 23:41:38 +0200. <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----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. <[email-masked]> 
Message-ID: <[email-masked]>

> > 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

(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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> > 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----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: <[email-masked]>
References: Your message of Mon, 12 Jan 2009 23:41:38 +0200.	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20090105/f913dd8b/attachment.txt>

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: <[email-masked]>

FYI,

-------- Original Message --------
Subject: hipl release 1.0.4
Date: Mon, 05 Jan 2009 18:02:49 +0200
From: Miika Komu <miika.komu at hiit.fi>
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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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