[hiprg] comments on draft-irtf-hiprg-proxies-01.txt

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Sun, 07 November 2010 04:36 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 69D3828C10D for <hiprg@core3.amsl.com>; Sat, 6 Nov 2010 21:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106
X-Spam-Status: No, score=-106 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id DR+VV3PjhfrX for <hiprg@core3.amsl.com>; Sat, 6 Nov 2010 21:36:25 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id DA23928C10C for <hiprg@irtf.org>; Sat, 6 Nov 2010 21:36:24 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com []) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oA74aGLm024832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Nov 2010 21:36:17 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost []) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oA74aGbZ025869; Sat, 6 Nov 2010 23:36:16 -0500 (CDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com []) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oA74aFFO025864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 6 Nov 2010 23:36:16 -0500 (CDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([]) by XCH-NWHT-02.nw.nos.boeing.com ([]) with mapi; Sat, 6 Nov 2010 21:36:15 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "'Dacheng Zhang'" <zhangdacheng@huawei.com>, "'???'" <xuxh@huawei.com>, "'shenshuo@cnnic.cn'" <shenshuo@cnnic.cn>
Date: Sat, 6 Nov 2010 21:36:13 -0700
Thread-Topic: comments on draft-irtf-hiprg-proxies-01.txt
Thread-Index: Actz7NZ2MrsDr7EaQzq3nMxbxb0y9QKLfwtw
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451AA8@XCH-NW-10V.nw.nos.boeing.com>
References: <20101025023007.0A11A3A63D3@core3.amsl.com>
In-Reply-To: <20101025023007.0A11A3A63D3@core3.amsl.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: [hiprg] comments on draft-irtf-hiprg-proxies-01.txt
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: Sun, 07 Nov 2010 04:36:26 -0000

Dacheng and all,

I read through your draft today and will privately send you some editorial comments but I have the following more substantial comments for you to consider.

First, would you be willing to consider some revisions to the acronyms/terminology?  Here are a few suggestions (I'm open to other suggestions but I think that some type of change would improve the readability of the draft, since it is easy to forget what are types 1, 2, 3 in later sections):

  Made-Up Legacy Host (ML) -> Legacy Host (LH)
  DI1 (DNS Intercepting Proxy type 1) -> DI-HIT
  DI2 (DNS Intercepting Proxy type 2) -> DI-NAT
  DI3 (DNS Intercepting Proxy type 3) -> DI-transparent
  prim proxy -> primary proxy

In section 3.4, it seems to me that it is possible to be a N-DI and a DI proxy simultaneously; i.e., the proxy functionalities may simultaneously be supported on the same server.

In section 3.4, you state that it is infeasible for an N-DI proxy to cache a packet and resolve it on the spot.  I don't really think this is infeasible; this type of behavior occurs in on-demand routing, and probably also in HIP hosts that need to resolve HITs to IP addresses.

In section 3.4, you also suggest that it may be possible to return HITs instead of IP addresses in HIP hosts' AAAA records.  I think this is not a good idea since it would effectively disable the ability to use DNS to contact the host outside of HIP, and it may confuse even other HIP hosts in the public network.

In section 4, you categorize load balancing techniques as being those that divide up the HIT pool or IP address pool statically between (load balancing) proxies.  Isn't another solution (more traditional) to just pool all proxy resources and delegate to free proxies?  It seems that there would be several scenarios in which such load balancing would work (basically, in any scenario where it can be guaranteed that the proxy selected can continue to be routed all of the packets of the flow).

In section 5.2, you talk about a special type of HIP proxy-aware DNS server that is aware of load-balancing and modifies its behavior accordingly.  I think that this could be avoided by either having the (load-balancing) proxies update the DNS on the current mapping, or if this is too much load, then use a RVS.

In section 9, you mention DNSSEC as a security consideration.  Typically, this section (security considerations) is about security concerns of the mechanisms introduced by the draft, while DNSSEC is really a deployment concern (or deployment hindrance) in this context.  Therefore, I suggest to move the DNSSEC concerns forward in the document to section 3 somewhere, and focus section 9 on security concerns of having these proxies in the network.

- Tom