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
- [Hipsec] HIP questions DONG Song RD-ILAB-LON
- RE: [Hipsec] HIP questions Joseph
- FW: [Hipsec] HIP questions DONG Song RD-ILAB-LON
- Re: FW: [Hipsec] HIP questions Julien Laganier
- RE: FW: [Hipsec] HIP questions DONG Song RD-ILAB-LON