[Hipsec] HIP questions

"DONG Song RD-ILAB-LON" <song.dong@francetelecom.com> Wed, 10 August 2005 14:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUo-0006cF-6t; Wed, 10 Aug 2005 10:23:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUl-0006c4-T7 for hipsec@megatron.ietf.org; Wed, 10 Aug 2005 10:23:52 -0400
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01884 for <hipsec@lists.ietf.org>; Wed, 10 Aug 2005 10:23:48 -0400 (EDT)
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:21:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 10 Aug 2005 16:21:37 +0200
Message-ID: <B877D90AB2240C4D84DF56169F1EAFED01DEE61B@ftrdmel3.rd.francetelecom.fr>
Thread-Topic: HIP questions
Thread-Index: AcWdttGypkUfBS3xTFmQwG3hV5ZyFw==
From: DONG Song RD-ILAB-LON <song.dong@francetelecom.com>
To: hipsec@ietf.org
X-OriginalArrivalTime: 10 Aug 2005 14:21:38.0922 (UTC) FILETIME=[D262B4A0:01C59DB6]
Cc:
Subject: [Hipsec] HIP questions
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="===============1424957348=="
Sender: hipsec-bounces@lists.ietf.org
Errors-To: hipsec-bounces@lists.ietf.org

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