[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identity persistence and comparison issues



marcelo bagnulo braun wrote:


Yes, but for how long does the hip endpoint maintains the mapping between the HIT and the locators of the other endpoints?

HIP:


For my best understanding, the HIP I-D does not explicitly specify the context lifetime.
Although, the IPSec Security Association lifetime plays an important role in HIP.
In our HIP implementation the IPSec SA is stricly bound to the HIP context. Once the
SA is deleted, so will be the corresponding HIP context.


When the SA lifetime expires, the IPSec typically triggers an UPDATE
message updating the SA. In our implementation, if the UPDATE exchange fails,
the host destroys the corresponding HIP context. In addition, in BSD, if there are no traffic
within t seconds, the SA expiration does not trigger a new UPDATE message, but just
deletes the SA, and as a consequence also the HIP context.


Multi6:

It seems to me that Multi6 wedge3.5 protocols could benefit from IPSec SA
kind of semantics. That is, each host specifies its own policy for context lifetime.
(It is good to notice that this proposal is not related to actual IPSec in anyway).
Once the context lifetime expires, it triggers a new context lifetime update exhange.
If the Multi6 implementation does not find out any traffic during a while, it
just deletes the context (like with IPSec in BSD). However, the next packet
sent via the open socket would trigger a new full context establishment exchange.


Any opinions?


I mean, there must be a garbage collection mechanism, if not the hip endpoint will have to store infromation about all the endpoints that it has communicated with in the past


You are right that there exists a problem. A host that destroys a HIP context may still
have an open socket bound to HITs. Now, if an application sends a packet using the
HITs, the packet triggers new HIP base exchange. However, the host does not have
anymore information about the destination locators where to send the HIP base
exchange packets. Thus, we end up with problems.


I would like to see a Multi6 variant of HIP that uses routable IP-addresses as
application identifers, instead of HITs.
(I will return to this topic in my reply to Erik, in the next mail.)


br, Jukka

--
Jukka Ylitalo                      Tel: +358 9 299 2622
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 400 615 821
FIN-02420 Jorvas, Finland          E-mail: jukka.ylitalo@nomadiclab.com