[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