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

["Henderson, Thomas R" <[e-mail]>]

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