Host Identity Protocol

This is going to be an uncherictersticaly short post; however I am woundering what is up with the Host Identity Protocol? For those who do not know the HIP allows for the implemntation of the HIT or Host Identity Tag. This is designed to solve the issue of moblie people losing thier sessions and streams when moving between networks. The assumption is that all, or atleast the majority, of services identify a client based upon there IP address. Acording to the abstract this will also make setting up servers behind NAT fierwalls easyer and increase security by uniqly identifying each host similer to an ssh finger print.

However I have three questins that leasd me to ask why this is a real projects:

1) Session ID's - When an application server needs to indentify a client they issue a session id to the client. For example when you hit my tomcat server and start a particuler session I don't care what network the client is on or what physical server the client may be hitting, I need to identify the client for the life of his session. Session ID's are already in place - so what what portion of session ID's fails so badly that it needs to be replaced with an entierly seporate project?

2) Existing Identifyers - Why not use existing identifiers such as the MAC address of the clients network interface? While it is true that ones IP can change all to frequently during the cource of a normal mobile operation, the MAC does not.

3a) Security Vs. Privacy - The answer to the above question leads to my final concern. Mac addresses can change when one user changes network interfaces. However the protocol sugested, as I understand it, sits between the Addressing and Transport layers. This is tradtionaly tied to a network interface thus changing interfaces would also change your HIT. The other one would be that MAC addresses can be esaly changed and this breaks it from being a consistant and secure identifyer. But HIP suffers from this as well.

3b) Security Vs. Privacy - There was a way to solve this security issue introduced back in the 90's; it was called CPU ID. This was a hardware based ID that was easy for all applications to read but very difficult to change or mask. The problem soon became that everyone screamed PRIVACY! It turns out people do not want to be uniquely identified with all of there activities on line at all times. As such manufactures quickly included the option to volunteerly turn off CPUID, and that was so popular it started to come turned off by default. This, of course, made it a completely invalid identifier.

So, unless you planning on replacing an entirely server side expiration based session ID I do not see how this will work. However, at the same time, I can not see why you want to replace session ID's. This leaves me to ask - Why is this a real project?

This is an actually question I am hoping some one can answer so please feel free to comment to this via the blog comments, or like most of you do, via twitter or facebook.