RE: [Hipsec] HIP questions

"Joseph" <joseph-so@gmx.net> Wed, 10 August 2005 14:54 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxz-0007Ln-Kv; Wed, 10 Aug 2005 10:54:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxx-0007LX-CV for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 10:54:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03961 for <hipsec@ietf.org>; Wed, 10 Aug 2005 10:53:58 -0400 (EDT)
Message-Id: <200508101453.KAA03961@ietf.org>
Received: from mail-09.iinet.net.au ([203.59.3.41] helo=mail.iinet.net.au) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2sVr-0000sF-HM for hipsec@ietf.org; Wed, 10 Aug 2005 11:29:17 -0400
Received: (qmail 15216 invoked from network); 10 Aug 2005 14:53:28 -0000
Received: from unknown (HELO T40) (203.217.39.9) by mail.iinet.net.au with SMTP; 10 Aug 2005 14:53:25 -0000
From: Joseph <joseph-so@gmx.net>
To: 'DONG Song RD-ILAB-LON' <song.dong@francetelecom.com>, hipsec@ietf.org
Subject: RE: [Hipsec] HIP questions
Date: Thu, 11 Aug 2005 00:53:18 +1000
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <B877D90AB2240C4D84DF56169F1EAFED01DEE61B@ftrdmel3.rd.francetelecom.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcWdttGypkUfBS3xTFmQwG3hV5ZyFwABGWFQ
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 2d59e8aabfccff976bdddd3996aba7a3
Cc:
X-BeenThere: hipsec@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@lists.ietf.org>
List-Help: <mailto:hipsec-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0567018776=="
Sender: hipsec-bounces@lists.ietf.org
Errors-To: hipsec-bounces@lists.ietf.org

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: hipsec-bounces@lists.ietf.org [mailto:hipsec-bounces@lists.ietf.org]
On Behalf Of DONG Song RD-ILAB-LON
Sent: Thursday, August 11, 2005 12:22 AM
To: hipsec@ietf.org
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
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec