Subject: FW: [Hipsec] HIP questions

From: "DONG Song RD-ILAB-LON" <[email-masked]>
Date: Wed, 10 Aug 2005 17:46:41 +0200

Joseph  and others ,
 
Thanks for your reply. Here are my points.
 
Whether using DNS or RVS, as I said is to provide the translation
information to the server or the correspondent node (CN). RVS happens
similarly to the Routing Optimisation in IPv6 by binding with CN
directly. Even with RVS, you still need to report your presence to the
DNS server in order for another person to connect you. The information
in the DNS also needs freshly updated.
 
I didn't say MIP brings more security than HIP. Actually, it has no
security except registration authentication. MIP plus IPsec can does the
same as HIP is trying to do. Perhaps MIP could absorb the idea of Host
Identifier (public key) to enhance itself, but definitely not by
introducing another name space for the transport layer to use.
 
Regards,
Song
p.s. I would be very interesting to read your paper if it is ready.

________________________________

From: Joseph [mailto:[email-masked]] 
Sent: 10 August 2005 15:53
To: DONG Song RD-ILAB-LON; [email-masked]
Subject: RE: [Hipsec] HIP questions

Dear Song and other folk (who read this email),

           I think that HIP can replace MIP or co-operate with MIP, if
commercial consideration is not included. (Just similar to many people
said that IPv4 should be replaced by IPv6 within 2-5 years, when I was
high school student. However, I'm postgraduate student now; IPv4 is not
replaced yet.

           In the Mobility part, I want to make some notes. Beside the
DNS server, we can use RVS to map between HI/HIT and MIP. The
performance of RVS in the mobility area of HIP is much better than DNS.
Furthermore, during the communication, mobile node can use update packet
to readdressing. As the SA is not bonded to IP, so that the connection
can be mapped into different IP address. I have even written a paper to
talk about the initial merging in MIP and HIP. (I have submitted to
conference, I can send to you if you are interested when the paper is
accepted). For the security, I think HIP is much strength than MIP, in
ESP connection mode, all the package are protected by ESP, but MIP is
not.

           I'm an also new baby in HIP, I think there are a lot of
professional in here can tell you more detail about the advantage about
HIP over MIP. I think the problem of HIP not able to replace MIP is not
technical, but commercial reason. 

           Please correct me if I have any mistake.

Yours,

Joseph

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of DONG Song
RD-ILAB-LON
Sent: Thursday, August 11, 2005 12:22 AM
To: [email-masked]
Subject: [Hipsec] HIP questions

Hi all, 

I recently have a study on HIP. Some people say it easily supports
mobility by introducing HIP layer to separate transport layer and IP
layer. Therefore it will even replace MIP. I don't think so. Following
is my conclusion. If anybody could point out my misunderstanding, that
will be very helpful. Pls keep the reading frame as large as possible in
order to have a correct display of the diagrams.

Thanks, 
Song 

France Telecom R&D UK 

The Host Identity Protocol (HIP) is a key establishment and parameter
negotiation protocol.  Its primary applications are for authenticating
host messages based on host identities, and establishing security
associations (SAs) for ESP transport format and possibly other protocols
in the future.

The authors also think it could bring more efficient mobility by
decoupling the transport layer and internetworking layer. I personally
don't believe it will pose any impact on Mobile IP.

Here are my analysis. 

Mobility: 
There are mainly two address spaces in use in the internet. In order for
two hosts to communicate with each other, an address space which could
represent their physical places and is easy to route is required. That
is the internetworking address (IP address). Another type of addresses
are Domain names, including email address, http, and SIP addresses,
which are easy to memorize and used directly by applications.

Therefore the communication process will normally be as follows: 

                                                Transport Layer 
                                                        | 
                                                        | 
                    DNS Server (translator)     
Domain Name   ---------------------------------------------------> IP
address 

The domain name will be tranlated into a IP address which represents the
host's physical presence. Because the normal IP address is physically
bound. The translation information located in DNS server is normally
static and does not need dynamic(real time) update.

However, because the IP address is bound to a physical site in the
internet. It presents a problem for the application mobility since the
transport layer is using the IP address. In this case, some sort of IP
address which is not physically bound and can stay fixed during the
communication is needed for the transport layer to use. That is the
introduction of Mobile IP as follows:

                                        Transport Layer 
                                                   | 
                                                       | 
                DNS Server (translator)
Home Agent (translator) 
Domain Name ----------------------------------> Mobile IP Home Address
------------------------------>  IP address (physical site)

                                               (static)
Dynamically                (might change)     

>From the Mobile IP address to the physically bound IP address, there
needs some sort of translator to provide the mapping information. That
is the function of the Home Agent. To support mobility, the information
must be updated dynamically along with the movement of the node. The
Mobile Node uses Registration Request message to provide such
information (or BU in IPV6).

Then let's look at how HIP works. 

It suggests using Host Identifier (HI) to decouple the transport layer
and the IP layer as follows: 

                                         Transport Layer 
                                                | 
                                                |

                DNS Server (translator)
DNS Server (translator) 
Domain Name ----------------------------------> Host Identifier Address
------------------------------>  IP address (physical site)

                                               (static)
Dynamically                (might change)     

Therefore, ithe transport can use the static HI address which will not
change during the communication. It seems perfect for mobility. However,
it is not true. The problem is that how the up-to-date mapping
information from the static HI address to the possible dynamic IP
address (if the node moves) is be obtained in the system. In the HIP
IETF draft, it says the DNS server is used to translate the Domain Name
into Host Identifier Address and IP address at the same time. No matter
whoever is to translate the information, such information must be
updated on a real-time style. Otherwise you are going to lose the trace
of the node. Therefore, you need some sort of scheme like Registration
Request and Registration Reply to provide such information to the
translator dynamically. Sounds familiar? Yes, you are going to reinvent
Mobile IP again. Never the less, because it introduces the static HI
address to replace the traditional IP address for the transport layer to
use, it requires fundmental changes for the transport layer and upper
layers, e.g. all socket APIs must be rewritten to support HI addresses.

I think the authors also recognised this. Let's look at its answer to
the IRTF Name Space Research Group (NSRG) on the translation/resolution.

   9.  What would the resolution mechanisms be, or what characteristics 
       of a resolution mechanisms would be required? 

          For most purposes, an approach where DNS names are resolved 
          simultaneously to HIs and IP addresses is sufficient. 
          However, if it becomes necessary to resolve HIs into IP 
          addresses or back to DNS names, a flat resolution 
          infrastructure is needed.  Such an infrastructure could be 
          based on the ideas of Distributed Hash Tables, but would 
          require significant new development and deployment. 

(Taken from: Host Identity Protocol Architecture draft-ietf-hip-arch-02)

Considering it brings similar functions to the Mobile IP while requiring
much more implement effort, I don't think it has any opportunity to
replace Mobile IP, which already has some applictions.

Security: 
However, it brings some novel ideas of security which could be used or
borrowed to deal with mobile security. 

Current Security IPsec Problem 
Current IPsec uses a local valid index SPI, the IP destination address,
and Security Protocol (AH/ESP) to find the cyper key in the local
database to decrypt the cipertext as follows:

cyper text 
SPI                                 local database
| 
IP destination address  ----------------------------------> cyper key
-------------------->| 
SP
| 
 
clear text 

However, in a case where the IP address changes, the node will never be
able to find the ciper key in its database using the index. Therefore,
the negotiation is needed to obtain another ciper key. That is why IPsec
is not working with a changed IP address.

In Mobile IP, it is possible to negotiate the ciper key using the node's
Home Address which will stay the same during the communication.
Therefore, the cyper key can be found. This is the case of what we say
IPsec inside Mobile IP tunnel. However, to support mobility, the node
needs to talk with the HA in clear text because the cyper key is only
used between the MN and the VPN gateway (or the CN). This brings the
requirement of IPsec splitting tunnel which might pose some security
risks.

Let's then look at what the HIP is trying to achieve. 

cyper text 
SPI                   local database
| 
HI Address   ----------------------------------> cyper key
-------------------->| 
SP
| 
 
clear text 

It suggests because the HI address is static, the cyper key could be
used even the node moves (IP address changes). It sounds good. But let's
look back at the mobility part. The mobile node needs to report the
mapping information from the static HI address to the changed IP address
dynamically to the translator (DNS server), of course, in clear text,
since the cyper key is between the mobile node and the VPN gateway / or
the CN. It has the same splitting tunnel problem.

Summary: 
To compare with MIP, HIP does not bring any new advantages or
functionalities on mobility and security. In addition, it requires heavy
development and fundmental changes for the tranport layer and upper
layers. My personally view is that it is never going to replace MIP or
mobility management.

It might do some help on security aspect using public / private key to
authenticate and exchange cyper key. Current IPsec VPN mainly uses
username and password to authenticate. However, this is not a new idea
as SSH is already using it. Definitly it is never going to happen that
the transport layer uses the HI address (public key) as the name space
to set up the communication.

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Wed, 10 Aug 2005 18:28:45 +0200

On Wednesday 10 August 2005 17:46, DONG Song RD-ILAB-LON wrote:
> information to the server or the correspondent node (CN). RVS
> happens similarly to the Routing Optimisation in IPv6 by binding
> with CN directly. Even with RVS, you still need to report your
> presence to the DNS server in order for another person to connect
> you. The information in the DNS also needs freshly updated.

When you use a RVS, you don't report your presence to the DNS nor do 
you updated it regularly. You just happen to store your RVS's IP 
address or FQDN, and then you only update the RVS with your current 
location.

> security except registration authentication. MIP plus IPsec can
> does the same as HIP is trying to do. Perhaps MIP could absorb the
> idea of Host Identifier (public key) to enhance itself, but
> definitely not by introducing another name space for the transport
> layer to use.

Well... In your first email you also wrote "all socket APIs must be 
rewritten to support HI addresses." 

First there's are no such HI addresses. There are HIs, HITs, and IP 
addresses. And as a matter of a fact, the mail client with which I 
write this message sits on vanilla socket API and TCP/IP stack (i.e. 
unmodified), in which HITs and IPv6 addresses have lived happily 
together in the same data structures for now more than three years.

--julien