Re: [Hipsec] New HIP WG charter proposal

Robert Moskowitz <rgm@htt-consult.com> Tue, 04 May 2010 13:48 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6790A3A692E for <hipsec@core3.amsl.com>; Tue, 4 May 2010 06:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.723
X-Spam-Level:
X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.724, 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 Ug0i255E26P7 for <hipsec@core3.amsl.com>; Tue, 4 May 2010 06:48:27 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 908AD3A6A70 for <hipsec@ietf.org>; Tue, 4 May 2010 06:48:26 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C6BC66829C; Tue, 4 May 2010 13:41:57 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGpQn8vr5jLL; Tue, 4 May 2010 09:41:48 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3413568A8C; Tue, 4 May 2010 09:41:44 -0400 (EDT)
Message-ID: <4BE02580.8060808@htt-consult.com>
Date: Tue, 04 May 2010 09:47:44 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: Erik Nordmark <erik.nordmark@oracle.com>
References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com>
In-Reply-To: <4BDFE5B7.3020500@oracle.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] New HIP WG charter proposal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2010 13:48:28 -0000

On 05/04/2010 05:15 AM, Erik Nordmark wrote:
> On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote:
>> Hi,
>>
>> as you know, we need to recharter the WG in order to move our specs to
>> the standards track. I have put together a charter proposal (see
>> attachment). Please, let me know if you have any comments on it.
>
> What is the current state of handling applications that do referrals 
> with HIP? Last time I looked there wasn't any useful support for this.

Here is pretty much what we have learned over the past many years...

If the referral is an IP address the following MAY occur:

If the app just issues an http://<addr>/<whatever> the HIP shim MAY 
perform an opportunistic HIP BEX and if successful proceed with the 
connection over HIP. If opportunistic failed or was not configured, then 
the connection will occur "open". That is without HIP.

If the app issues a reverse lookup on <addr> and retrieves a DNS HI 
record, then again, HIP would be used for the connection.

If the referral is a HIT, then the HIP shim would need some mechanism to 
perform the HIT to IP lookup. One would have to ASSuME that since a HIT 
was provided in a referral that a lookup mechanism was provided by the 
server and hopefully the client will use the 'right one'. One possiblity 
is DHT. Another is DNS. DNS reverse lookups of HITs is a problem, as 
they are flat within the ORCHID prefix (well flat within the new concept 
of HIT suites). This is where Hierarchical HITs MAY be of value.

So the short answer is: referrals work if the referral is an IP address. 
referrals MAY work if the referral is a HIT.

>
> I think preserving that part of the Internet architecture is important 
> in whatever we put on the standards track.

We all think this and see regular cases where things work only 
sometimes. I feel that in HIP we have found that it makes more things 
work (like IPv4 dumb apps running over IPv6 networks) than it makes 
things hard.

Perhaps the abouve discussion can be captured in one of the HIP 
documents if it is already not there.