Subject: [Hipsec-rg] About simultaneous mobility to HIP
From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 31 Jul 2008 09:50:40 -0700

> -----Original Message-----
> From: xuxiaohu 41208 [mailto:xuxh at huawei.com] 
> Sent: Thursday, July 31, 2008 4:26 AM
> To: Andrei Gurtov
> Cc: Andrew McGregor; hipsec-rg
> Subject: Re: [Hipsec-rg] About simultaneous mobility to HIP
> 
> 
> > 
> > I've commented to John in private that the use of DHT or 
> Hi3 (or even
> > fast enough DynDNS) could help in simultaneous mobility.
> 
> Hi all,
> 
> I have made a presentation of HRA(Hierarchical Routing 
> Architecture) on the HIPRG session this Monday, but no 
> comment received up to now.
> 
> The major differece between HRA and HIP is that HRA uses a 
> hierarchical and cryptographic hash identifier which is 
> composed of Administrative Domain (AD) ID and a hash of the 
> ADID and the public key. It looks like CGA. However, the AD 
> ID, which embeds organization semantics,is only routable on 
> the ID/locator mapping system which is realized by 
> Hierarchical DHT. The main purposes are 1)Enforce 
> organization-level access control policy 2)Overc
> ome the lack of economic&trust model in the id/locator 
> mapping system for the flat identifier.

I was not at the RG session but I read your draft again this morning.
My impression of HRA is that it should be submitted to the RRG for
consideration; there are a lot of routing aspects that are more in scope
of the RRG than the HIPRG.  My opinion is that it will be somewhat of a
hard sell to the RRG as is, because it is very much a clean slate design
of a routing architecture (which faces significant deployment hurdles),
and the draft does not offer much in terms of showing quantitative
benefit to justify the deployment challenges.

> 
> I wonder whether the flat HIT is good enough in the DHT or 
> Hi3 overlay from different perspectives.
> 

Regarding flat HIT vs. hierarchical HIT, this by itself is IMO a good
topic for discussion for this research group, because a hierarchical HIT
offers some improved resolution properties.

I think it is challenging to squeeze hierarchy/administrative bits into
the existing 128-bit field, because if we are constrained to use an
ORCHID prefix, then to get on the order of 32 bits of hierarchy we will
be down to roughly 70 bits of hash which compromises the ability to
survive the second preimage attack.  To me, this is problematic because
one of the key attributes of HIP is that the security of the binding
update is not easily compromised.

Another problem is to decide who owns and gets to allocate the bits
corresponding to the administrative domains.  Presumably, there would
need to be some security architecture to authenticate ownership of
certain bit patterns in that field, and would introduce some kind of
third party gatekeeper of the bits. 

However, if the bit constraints were reduced by going to larger HITs
(such as 256 bits) then I think that having some bits to identify the
overlay where the HIT may be resolved becomes more attractive, and if
there are a lot of administrative bits available, then the political
problems of administering them are somewhat reduced since they are not
so scarce.

- Tom

From: fabrice.hobaya at etu.enseeiht.fr (Fabrice HOBAYA)
Date: Thu, 31 Jul 2008 18:35:03 +0200
Subject: [Hipsec-rg] =?gb2312?b?u9i4tCA6UmU6IEFib3V0IHNpbXVsdGFuZW91cyBt?= =?gb2312?b?b2JpbGl0eSB0byBISVA=?=
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

   FYI, in the context of my research master I am working on HIP and
specially on simultaneous moves issues at Thales France. I have
designed and implemented a solution based on OpenHIP version 0.5 (in
its user mode). A demonstrator is being developped with the prototype
implementation.

   Considering two mobile nodes that moves at or about the same time,
the main idea of our solution is to relay the two crossing UPDATE
exchanges initiated by the two mobile nodes through the respective
RVSs. The second packet of the UPDATE exchange (UPDATE with Echo
Request) is not relayed by the RVS as it aims at achieving an address
verification. The third packet of the UPDATE exchange (UPDATE with
Echo Response) is relayed by RVS, indeed as there are two crossing
UPDATE exchanges, when the third UPDATE packet is sent, the current
localization of the correspondent peer may not be known (verified)
yet.

   I am writting a publication to expose the design and the
implementation of my solution.

   If you are interested in my work, I would be happy to provide you details.

Regards,

Fabrice.

2008/7/31 xuxiaohu 41208 <xuxh at huawei.com>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> I suppose there is a danger in splitting the host identifier in
>> severalsubdomains that it stops to be an identifier and becomes a
>> locator. This
>> is exactly like IP address space is allocated, from national to
>> regionalISP down to company up to the user. What happens e.g. if
>> ISP A has own
>> host IDs and ISP B own host IDs and a host wants to handover between
>> providers? Then we have the same problems as currently with IP
>> addresses.
>
> Hi Andrei,
>
> I agree with you that the full hierarchy is not a good idea. However, I just want to change the identifier to be partialy hierarchical, for example, it just includes country code and region code. Just like FQDN (aslo with hierarchy), the identifier will remain relatively stable. For the flat identifier, I wonder who should run the DHT overlay for the id/locator mapping service.
>
> Xiaohu Xu
>
>
>>
>> xuxiaohu 41208 wrote:
>> |> I've commented to John in private that the use of DHT or Hi3
>> (or even
>> |> fast enough DynDNS) could help in simultaneous mobility.
>> |
>> | Hi all,
>> |
>> | I have made a presentation of HRA(Hierarchical Routing Architecture)
>> on the HIPRG session this Monday, but no comment received up to now.
>> |
>> | The major differece between HRA and HIP is that HRA uses a
>> hierarchical and cryptographic hash identifier which is composed of
>> Administrative Domain (AD) ID and a hash of the ADID and the
>> public key.
>> It looks like CGA. However, the AD ID, which embeds organization
>> semantics,is only routable on the ID/locator mapping system which is
>> realized by Hierarchical DHT. The main purposes are 1)Enforce
>> organization-level access control policy 2)Overc
>> | ome the lack of economic&trust model in the id/locator mapping
>> systemfor the flat identifier.
>> |
>> | I wonder whether the flat HIT is good enough in the DHT or Hi3
>> overlayfrom different perspectives.
>> |
>> | Any comment is welcomed.
>> |
>> | Xiaohu XU
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkiRsHgACgkQP7jp0uceFkQXUQCfYCercVob4mqy2i3bzMPY5G6S
>> wlQAoLYq0PfoHkfLRRoicxoXidzYlpHT
>> =fIf3
>> -----END PGP SIGNATURE-----
>>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>

-- 
Fabrice HOBAYA
fabrice.hobaya at etu.enseeiht.fr

From: xuxh at huawei.com (xuxiaohu 41208)
Date: Thu, 31 Jul 2008 15:48:24 +0100
Subject: [Hipsec-rg] =?gb2312?b?u9i4tCA6UmU6ICBBYm91dCBzaW11bHRhbmVvdXMg?= =?gb2312?b?bW9iaWxpdHkgdG8gSElQ?=
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I suppose there is a danger in splitting the host identifier in 
> severalsubdomains that it stops to be an identifier and becomes a 
> locator. This
> is exactly like IP address space is allocated, from national to 
> regionalISP down to company up to the user. What happens e.g. if 
> ISP A has own
> host IDs and ISP B own host IDs and a host wants to handover between
> providers? Then we have the same problems as currently with IP 
> addresses.

Hi Andrei,

I agree with you that the full hierarchy is not a good idea. However, I just want to change the identifier to be partialy hierarchical, for example, it just includes country code and region code. Just like FQDN (aslo with hierarchy), the identifier will remain relatively stable. For the flat identifier, I wonder who should run the DHT overlay for the id/locator mapping service.

Xiaohu Xu

> 
> xuxiaohu 41208 wrote:
> |> I've commented to John in private that the use of DHT or Hi3 
> (or even
> |> fast enough DynDNS) could help in simultaneous mobility.
> |
> | Hi all,
> |
> | I have made a presentation of HRA(Hierarchical Routing Architecture)
> on the HIPRG session this Monday, but no comment received up to now.
> |
> | The major differece between HRA and HIP is that HRA uses a
> hierarchical and cryptographic hash identifier which is composed of
> Administrative Domain (AD) ID and a hash of the ADID and the 
> public key.
> It looks like CGA. However, the AD ID, which embeds organization
> semantics,is only routable on the ID/locator mapping system which is
> realized by Hierarchical DHT. The main purposes are 1)Enforce
> organization-level access control policy 2)Overc
> | ome the lack of economic&trust model in the id/locator mapping 
> systemfor the flat identifier.
> |
> | I wonder whether the flat HIT is good enough in the DHT or Hi3 
> overlayfrom different perspectives.
> |
> | Any comment is welcomed.
> |
> | Xiaohu XU
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkiRsHgACgkQP7jp0uceFkQXUQCfYCercVob4mqy2i3bzMPY5G6S
> wlQAoLYq0PfoHkfLRRoicxoXidzYlpHT
> =fIf3
> -----END PGP SIGNATURE-----
> 

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 31 Jul 2008 17:44:07 +0300
Subject: [Hipsec-rg] materials from Dublin HIPRG meeting
Message-ID: <[email-masked]>

Slides are available at
http://datatracker.ietf.org/meeting/72/materials.html

Audio recording of the session
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch2-mon-noon.mp3

Unfortunately I forgot to ask for a minutes taker. Tom suggested to
reconstruct questions from the audio recording. If you have taken notes
during the session please send them to Tom and me.

Thanks
Andrei

From: john.zhao at huawei.com (John.zhao)
Date: Thu, 31 Jul 2008 14:06:29 +0100
Subject: [Hipsec-rg] About simultaneous mobility to HIP
Message-ID: <[email-masked]>

    See my comments inline.

======= 2008-07-31 14:03:00 You have said:=======

>
>Hi all,
>
>I've commented to John in private that the use of DHT or Hi3 (or even
>fast enough DynDNS) could help in simultaneous mobility.
[John.zhao]Agree. Currently , there are some much mature technolgoy can be used to review the resolution of this problem. But whatever is used, I mean among RVS,DHT or Hi3 etc, it seems that a fixed or respective fixed entity is need and the key to this case. So , it is similiar from this perspective. If that can be considered some harmonized and output one guideline as detail as possible for deployment?
>
>If I recall right, earlier revisions of rvs or mm drafts used to have
>extensive flow charts for various mobility scenarios but were removed
>later for simplicity/lack of interest. Might be useful to check history
>at http://tools.ietf.org/html/draft-ietf-hip-mm-00
[John.zhao]Just checked with those historic version. All version said the specific solution is out of scope.Although all of them mention about it and also mention about RVS solution to it.
>
>Andrei
>
>| ======= 2008-07-31 21:46:00 You have said:=======
>|
>|> This is what the concept of a Rendezvous Server is intended to solve.
>|> The (perhaps undocumented) idea is that a host should maintain
>|> connectivity to one such that is unlikely to move, and to advertise
>|> its locator as a potential rendezvous point.
>| [John.zhao] Agree from my opinion. But is it ok? And how about the
>detail chart flow? Is it should be and can be standarded as a doc at
>now? After all , without a document, something is uncertain.
>|> Andrew
>|>
>|> On 31/07/2008, at 9:32 PM, John.zhao wrote:
>|>
>|>> Hi,folks
>|>>
>|>> 	After take a look about current docs located in hip wg and hip rg.
>|>> I didn't find the document to describe how to resolve the
>|>> simultaneous mobility problem aimed to hip. If anyone have some
>|>> clues , hope can be shared.
>|>> 	If not,is it ok to start it?

= = = = = = = = = = = = = = = = = = = =
	Best Rgds,
Thanks,

John.zhao			

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 31 Jul 2008 15:30:48 +0300
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I suppose there is a danger in splitting the host identifier in several
subdomains that it stops to be an identifier and becomes a locator. This
is exactly like IP address space is allocated, from national to regional
ISP down to company up to the user. What happens e.g. if ISP A has own
host IDs and ISP B own host IDs and a host wants to handover between
providers? Then we have the same problems as currently with IP addresses.

Andrei

xuxiaohu 41208 wrote:
|> I've commented to John in private that the use of DHT or Hi3 (or even
|> fast enough DynDNS) could help in simultaneous mobility.
|
| Hi all,
|
| I have made a presentation of HRA(Hierarchical Routing Architecture)
on the HIPRG session this Monday, but no comment received up to now.
|
| The major differece between HRA and HIP is that HRA uses a
hierarchical and cryptographic hash identifier which is composed of
Administrative Domain (AD) ID and a hash of the ADID and the public key.
It looks like CGA. However, the AD ID, which embeds organization
semantics,is only routable on the ID/locator mapping system which is
realized by Hierarchical DHT. The main purposes are 1)Enforce
organization-level access control policy 2)Overc
| ome the lack of economic&trust model in the id/locator mapping system
for the flat identifier.
|
| I wonder whether the flat HIT is good enough in the DHT or Hi3 overlay
from different perspectives.
|
| Any comment is welcomed.
|
| Xiaohu XU

From: xuxh at huawei.com (xuxiaohu 41208)
Date: Thu, 31 Jul 2008 12:25:35 +0100
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> I've commented to John in private that the use of DHT or Hi3 (or even
> fast enough DynDNS) could help in simultaneous mobility.

Hi all,

I have made a presentation of HRA(Hierarchical Routing Architecture) on the HIPRG session this Monday, but no comment received up to now.

The major differece between HRA and HIP is that HRA uses a hierarchical and cryptographic hash identifier which is composed of Administrative Domain (AD) ID and a hash of the ADID and the public key. It looks like CGA. However, the AD ID, which embeds organization semantics,is only routable on the ID/locator mapping system which is realized by Hierarchical DHT. The main purposes are 1)Enforce organization-level access control policy 2)Overc
ome the lack of economic&trust model in the id/locator mapping system for the flat identifier.

I wonder whether the flat HIT is good enough in the DHT or Hi3 overlay from different perspectives.

Any comment is welcomed.

Xiaohu XU

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 31 Jul 2008 14:03:36 +0300
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

I've commented to John in private that the use of DHT or Hi3 (or even
fast enough DynDNS) could help in simultaneous mobility.

If I recall right, earlier revisions of rvs or mm drafts used to have
extensive flow charts for various mobility scenarios but were removed
later for simplicity/lack of interest. Might be useful to check history
at http://tools.ietf.org/html/draft-ietf-hip-mm-00

Andrei

John.zhao wrote:
| Hi,Andrew
|
| 	See my comments inline.
|
| 	Best Rgds,
| Thanks
|
| John.zhao
| ======= 2008-07-31 21:46:00 You have said:=======
|
|> This is what the concept of a Rendezvous Server is intended to solve.
|> The (perhaps undocumented) idea is that a host should maintain
|> connectivity to one such that is unlikely to move, and to advertise
|> its locator as a potential rendezvous point.
| [John.zhao] Agree from my opinion. But is it ok? And how about the
detail chart flow? Is it should be and can be standarded as a doc at
now? After all , without a document, something is uncertain.
|> Andrew
|>
|> On 31/07/2008, at 9:32 PM, John.zhao wrote:
|>
|>> Hi,folks
|>>
|>> 	After take a look about current docs located in hip wg and hip rg.
|>> I didn't find the document to describe how to resolve the
|>> simultaneous mobility problem aimed to hip. If anyone have some
|>> clues , hope can be shared.
|>> 	If not,is it ok to start it?
|>> 	
|>>
|>> 	Best Rgds,
|>> Thanks,
|>> 				
|>>
|>> 	???????? John.zhao
|>> ??	?	?????john.zhao at huawei.com
|>> ???	?	??????2008-07-31

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 31 Jul 2008 11:07:29 +0100
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Andrew McGregor wrote:
> This is what the concept of a Rendezvous Server is intended to solve.  
> The (perhaps undocumented) idea is that a host should maintain 
> connectivity to one such that is unlikely to move, and to advertise 
> its locator as a potential rendezvous point.
At the very first BOF on HIP, Steve Derring (sp!), pointed out that if I 
could not solve the 2-party move, then HIP was not deployable (or some 
such wording).  At that time the state machines (there were 2 at that 
time, one for the Initiator, and one for the Responder) could handle one 
move or the other, but not both.

That night, some people talking with me (mostly Hugh Daniels) pushed me 
to invent the Rendezvous Server.  Later Hugh and Andrew and Pekka 
greatly improved on it.

In actual usage, the Initiator MAY assume that the address it has for 
the Responder is a Rendezvous Server address, not the actual address of 
the Responder.  The Responder SHOULD always tell the Intiator its 
current RVS and the Initiator SHOULD always provide its RVS.  If you 
look at the state machine, given this, the hosts can rediscover 
themselves quickly.  A host that moves can inform all of its SAs of any 
readdressing.

Magic happens  :)

Just sitting here in the Internetworking meeting listing to IPv4/IPv6 
funness.

Alway, go look at the RVS.
>
> Andrew
>
> On 31/07/2008, at 9:32 PM, John.zhao wrote:
>
>> Hi,folks
>>
>>     After take a look about current docs located in hip wg and hip 
>> rg. I didn't find the document to describe how to resolve the 
>> simultaneous mobility problem aimed to hip. If anyone have some clues 
>> , hope can be shared.
>>     If not,is it ok to start it?
>>     
>>
>>     Best Rgds,
>> Thanks,
>>                
>>
>>     ???????? John.zhao
>> ??    ?    ?????john.zhao at huawei.com
>> ???    ?    ??????2008-07-31
>> _______________________________________________
>> 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: john.zhao at huawei.com (John.zhao)
Date: Thu, 31 Jul 2008 11:07:16 +0100
Subject: [Hipsec-rg] About simultaneous mobility to HIP
Message-ID: <[email-masked]>

Hi,Andrew

	See my comments inline.

	Best Rgds,
Thanks

John.zhao
======= 2008-07-31 21:46:00 You have said:=======

>This is what the concept of a Rendezvous Server is intended to solve.   
>The (perhaps undocumented) idea is that a host should maintain  
>connectivity to one such that is unlikely to move, and to advertise  
>its locator as a potential rendezvous point.
[John.zhao] Agree from my opinion. But is it ok? And how about the detail chart flow? Is it should be and can be standarded as a doc at now? After all , without a document, something is uncertain.
>
>Andrew
>
>On 31/07/2008, at 9:32 PM, John.zhao wrote:
>
>> Hi,folks
>>
>> 	After take a look about current docs located in hip wg and hip rg.  
>> I didn't find the document to describe how to resolve the  
>> simultaneous mobility problem aimed to hip. If anyone have some  
>> clues , hope can be shared.
>> 	If not,is it ok to start it?
>> 	
>>
>> 	Best Rgds,
>> Thanks,
>> 				
>>
>> 	???????? John.zhao
>> ??	?	?????john.zhao at huawei.com
>> ???	?	??????2008-07-31
>> _______________________________________________
>> Hipsec-rg mailing list
>> Hipsec-rg at listserv.cybertrust.com
>> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

= = = = = = = = = = = = = = = = = = = =

From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Thu, 31 Jul 2008 12:56:55 +0300
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

If both peers move at the same time, the update mechanism does not work
because both peers changed addresses at the same time and there is no
address that has been successfully connectivity tested. One way to solve
this is to use rendezvous server as a "home server".

http://infrahip.hiit.fi/hipl/manual/ch14s03.html

When both peers are mobile and the connectivity tests fail, peers should
try to find other peers RVS server and contact it through it. You could
also look RFC 5204 .

Cut-and-paste from RFC 5206 mobility and multihoming where this is
mentioned also

   There are a number of situations where the simple end-to-end
   readdressing functionality is not sufficient.  These include the
   initial reachability of a mobile host, location privacy, simultaneous
   mobility of both hosts, and some modes of NAT traversal.  In these
   situations, there is a need for some helper functionality in the
   network, such as a HIP rendezvous server [RFC5204].

BR
Samu Varjonen

John.zhao wrote:
> Hi,folks
> 
> 	After take a look about current docs located in hip wg and hip rg. I didn't find the document to describe how to resolve the simultaneous mobility problem aimed to hip. If anyone have some clues , hope can be shared. 
> 	If not,is it ok to start it?
> 	
> 
> 	Best Rgds,
> Thanks,
>  				
> 
> 	???????? John.zhao
> ??	?	?????john.zhao at huawei.com
> ???	?	??????2008-07-31
> _______________________________________________
> 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: Thu, 31 Jul 2008 21:46:19 +1200
Subject: [Hipsec-rg] About simultaneous mobility to HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is what the concept of a Rendezvous Server is intended to solve.   
The (perhaps undocumented) idea is that a host should maintain  
connectivity to one such that is unlikely to move, and to advertise  
its locator as a potential rendezvous point.

Andrew

On 31/07/2008, at 9:32 PM, John.zhao wrote:

> Hi,folks
>
> 	After take a look about current docs located in hip wg and hip rg.  
> I didn't find the document to describe how to resolve the  
> simultaneous mobility problem aimed to hip. If anyone have some  
> clues , hope can be shared.
> 	If not,is it ok to start it?
> 	
>
> 	Best Rgds,
> Thanks,
> 				
>
> 	???????? John.zhao
> ??	?	?????john.zhao at huawei.com
> ???	?	??????2008-07-31
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: john.zhao at huawei.com (John.zhao)
Date: Thu, 31 Jul 2008 10:32:04 +0100
Subject: [Hipsec-rg] About simultaneous mobility to HIP
Message-ID: <[email-masked]>

Hi,folks

	After take a look about current docs located in hip wg and hip rg. I didn't find the document to describe how to resolve the simultaneous mobility problem aimed to hip. If anyone have some clues , hope can be shared. 
	If not,is it ok to start it?

	Best Rgds,
Thanks,

	???????? John.zhao
??	?	?????john.zhao at huawei.com
???	?	??????2008-07-31

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 23 Jul 2008 08:12:49 -0700
Subject: [Hipsec-rg] draft-irtf-hip-experiment-04
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander at nomadiclab.com] 
> Sent: Tuesday, July 22, 2008 12:38 AM
> To: Andrei Gurtov
> Cc: hipsec-rg at honor.trusecure.com
> Subject: Re: [Hipsec-rg] draft-irtf-hip-experiment-04
> 
> Quick notes based on a very quick review:
> 
> - Section 2.1 focuses only on a BEET-like implementation, where the  
> IPsec part of the stack is extended.  As discussed a few years ago  
> within some IPsec-related WG (no longer remember which one), such an  
> implementation is unacceptable to some IPsec folks.  Therefore, it  
> would be good to describe also the alternatives, such as using plain  
> transport mode IPsec with HITs, and then doing NAT-like translation  
> below the IPsec layer, without touching the PF_KEY API or 
> IPsec at all.
> 
> - Section 4.1 could also briefly mention the DNS proxying 
> approach, in  
> which case no library changes are required?
> 
> It would be good to start getting some kind of conclusions.  I think  
> we start to be far enough so that we start to understand all the  
> issues in the small scale, and can probably extrapolate most (if not  
> all) of them to larger scale.

Pekka, thanks for reviewing.  I briefly mentioned to Andrei when doing
this latest resubmission that I'd like to see a major revision of the
document for -05 version, because I think it is drifting a bit from its
purpose which is to provide some conclusions or guidance back to the
IESG.  We probably have to refocus the text on that.

I think we are starting to understand the issues regarding how HIP might
impact people who deploy it as experimental software on their machine,
but we have little feedback, in my opinion, on other deployment issues
such as infrastructure (name server, rendezvous server) deployment,
managing HIP keys, or NAT traversal, for instance.

It is quite expensive to conduct grand experiments so one way I have
been thinking of starting again to work the issue would be to conduct a
preliminary analysis or use case development of what would it take for
some large commercial enterprise to deploy and manage HIP to ~100,000
devices, or for some large complicated network (think, for example, the
civil aviation environment with multiple service providers, regional
control centers in different countries, planes from many different
commercial airlines, and airports) to use HIP, or for a new
NAT-traversing P2P application to co-deploy with HIP on the IPv4
Internet.  Then, such use case development might motivate more targeted,
manageable experiments.

Tom

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Tue, 22 Jul 2008 10:38:00 +0300
Subject: [Hipsec-rg] draft-irtf-hip-experiment-04
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Quick notes based on a very quick review:

- Section 2.1 focuses only on a BEET-like implementation, where the  
IPsec part of the stack is extended.  As discussed a few years ago  
within some IPsec-related WG (no longer remember which one), such an  
implementation is unacceptable to some IPsec folks.  Therefore, it  
would be good to describe also the alternatives, such as using plain  
transport mode IPsec with HITs, and then doing NAT-like translation  
below the IPsec layer, without touching the PF_KEY API or IPsec at all.

- Section 4.1 could also briefly mention the DNS proxying approach, in  
which case no library changes are required?

It would be good to start getting some kind of conclusions.  I think  
we start to be far enough so that we start to understand all the  
issues in the small scale, and can probably extrapolate most (if not  
all) of them to larger scale.

--Pekka

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Tue, 22 Jul 2008 10:14:05 +0300
Subject: [Hipsec-rg] draft-irtf-hip-experiment-04
Message-ID: <[email-masked]>

There is a new version of HIP experiment report available

http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-04.txt

Andrei

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Tue, 15 Jul 2008 10:08:09 +0200
Subject: [Hipsec-rg] New version: draft-heer-hip-middle-auth
Message-ID: <[email-masked]>

Hi folks,

There is a new version of the middle auth draft.
Changes since version 00:

- New section about security and bindings between HIP and ESP traffic
- Rewrite and extension of the discussion of the security properties.
- Minor fixes for alignment with the base documents (packet sizes)

Abstract:
The Host Identity Protocol [RFC2119]is a signaling protocol for
secure communication, mobility, and multihoming by introducing a
cryptographic namespace.  This document specifies an extension for
HIP that enables middleboxes to unambiguously verify the identities
of hosts that communicate across them.  This extension enables
middleboxes to verify the liveness and freshness of a HIP association
and, thus, enables reliable and secure access control in middleboxes.

Comments are very appreciated.

The draft can be found here:
http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-01.txt

BR,

Tobias

Anfang der weitergeleiteten E-Mail:

> Von: IETF I-D Submission Tool <idsubmission at ietf.org>
> Datum: 7. Juli 2008 16:07:47 MESZ
> An: heer at cs.rwth-aachen.de
> Kopie: wehrle at cs.rwth-aachen.de, miika at iki.fi
> Betreff: New Version Notification for draft-heer-hip-middle-auth-01
>
>
> A new version of I-D, draft-heer-hip-middle-auth-01.txt has been  
> successfuly submitted by Tobias Heer and posted to the IETF  
> repository.
>
> Filename:	 draft-heer-hip-middle-auth
> Revision:	 01
> Title:		 End-Host Authentication for HIP Middleboxes
> Creation_date:	 2008-07-07
> WG ID:		 Independent Submission
> Number_of_pages: 22
>
> Abstract:
> The Host Identity Protocol [RFC2119]is a signaling protocol for
> secure communication, mobility, and multihoming by introducing a
> cryptographic namespace.  This document specifies an extension for
> HIP that enables middleboxes to unambiguously verify the identities
> of hosts that communicate across them.  This extension enables
> middleboxes to verify the liveness and freshness of a HIP association
> and, thus, enables reliable and secure access control in middleboxes.
>
>
>
> The IETF Secretariat.
>

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer