[hiprg] Comments on draft-wang-hiprg-service-overlay-00
Ari Keranen <ari.keranen@nomadiclab.com> Tue, 06 April 2010 12:30 UTC
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560B23A6837 for <hiprg@core3.amsl.com>; Tue, 6 Apr 2010 05:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zchbISRDvVYg for <hiprg@core3.amsl.com>; Tue, 6 Apr 2010 05:30:51 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1B0EF3A6823 for <hiprg@irtf.org>; Tue, 6 Apr 2010 05:30:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E0D354E6CD for <hiprg@irtf.org>; Tue, 6 Apr 2010 15:30:45 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh+TyUZKcQBF for <hiprg@irtf.org>; Tue, 6 Apr 2010 15:30:45 +0300 (EEST)
Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 50B2B4E6C8 for <hiprg@irtf.org>; Tue, 6 Apr 2010 15:30:45 +0300 (EEST)
Message-ID: <4BBB2975.3020806@nomadiclab.com>
Date: Tue, 06 Apr 2010 15:30:45 +0300
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: hiprg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [hiprg] Comments on draft-wang-hiprg-service-overlay-00
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 12:30:53 -0000
Hi, Here are some comments on the HIP service overlay draft. Overall, the draft's idea is somewhat interesting, but there are some issues I would not fully agree on (or that I may not have understood correctly). 1. Introduction #1. Before one host wants to communicate with another host, it MUST initiate a HIP 4-way handshake, and then initiate a TCP handshake and other transport or application connections. It leads to a long connection delay and downgrades the user experience. You can piggyback the TCP handshake or any other transport stuff to the I2/R2 exchange if you really wish to mitigate this issue, but due to DoS resistance it may not be a good idea. Anyway, the analyzed indirection solutions (sending packets via overlays) would likely create more delay than the basic 4-way handshake, right? Also, I'd say "host can" instead of "host wants to". #2. When the underlying link broken, the initiator doesn't know the link had broken until it has gotten O(n^2) fail attempts, in which the n is the number of one multihoming host's locators. If only one link is broken, wouldn't the other links still work if the host is multihoming? Or do you mean that if the *all* links are broken? #3. End-to-End communication model depends on the PKI infrastructure, but existing widely deployed telecomm network employs pre-shared key security mechanism rather than PKI. So if HIP can support pre-shared key authentication, the existing infrastructure can be reused. Self generated identities are quite standard with HIP, so I wouldn't agree with depending on a PKI. And you can use certificates to sign the self-generated keys and the certificates can be obtained using a pre-shared key (say, one logins to a web page that authenticates the user) to accomplish the same functionality but in a cleaner way. That said, also I have earlier proposed a pre-shared key (password) based authentication in the draft-keranen-hip-native-nat-traversal-00, before concluding that it may not be that good idea (the next version will use certificates instead). #4. Since HIP mobility mechanism does not use any anchor point, if a HIP host's IP address changed, it must sends an update message to its connected peer. Such design makes the mobility possible even if infrastructure does not involved, but it also causes two weaknesses: 1)If the connection peer resides in a different continent or if the HIP host has too many connections, the update may be time-consuming and leads to very high handover delay. 2)If two hosts of one connection change their IP addresses simultaneously, the update could never be successful. I'm not sure if I fully understand this. Wouldn't RVS or a HIP relay server work as an "anchor point"? This should solve your 2nd point. And regarding the first point, I assume you are referring to a high RTT when you talk about peers in different continent? 3.1. i3 For the four issues listed in introduction part, as i3 does not need HIP handshake, the issue #1 goes away; and as hosts always send packages to i3 infrastructure, and update i3 infrastructure about it's IP address changes, so issue #2, #3 and #4 also can be resolved. I'm not sure if the comparison between i3 and HIP is really a meaningful one. For example, sure you don't need PKI with i3, but you don't need one with HIP either to get the same level of security. Also, making a 4-way hand shake is probably most of the time faster than going via i3 overlay, so I would not agree that #1 is better with i3. 3.2. Hi3 Hi3 uses i3 as control plane for forwarding HIP handshake packages I1, I2, R1 and R2, but still uses end to end PKI infrastructure and end to end HIP connection as data plane, so the issues #1, #2, #3 and #4(1) listed in introduction part still exist. Actually, using direct HIP connection on the data plane makes this much more efficient than routing all the data via an overlay (as in i3). And you really don't need the PKI with Hi3 either. 4.2. Registration procedure Probably intentionally (being -00 version), there are a lot of details missing on how the registration is actually done, so it's hard to evaluate it. 4.3. Initiating a communication When a HIP client initiates a connection to a new peer, e.g. sends a TCP SYN packet to a new host, the client's HIP stack inserts a proxy address, which is gotten from registration procedure, into the HIP packet and routing the packet to the HAP which has the proxy address. So is the TCP SYN carried in a HIP (DATA?) packet over the overlay? 4.4. Updating location In this specification, the HIP host does not need to notify the location change to the communicating hosts directly, thus reducing the extra connection delay. I think you could accomplish the same with a HIP data relay (see draft-keranen-hip-native-nat-traversal) but without the overlay overhead. 8. References You should add the reference pointers to appropriate places in the text; now you have none. Cheers, Ari