[Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01

I would like to point out that this work seems related to the work  
going on
in the P2PSIP working group, and some recent efforts to link HIP and  
P2PSIP.
In particular, I see the following parallels:

1) http://tools.ietf.org/html/draft-singh-p2p-sip-00  describes  
another interface
to OpenDHT for storing contact information for SIP users. It seems to be
looking at similar problems.

2) http://tools.ietf.org/html/draft-matthews-p2psip-hip-hip-00  
describes a way
to have a number of HIP nodes cooperate to form an overlay structured as
a DHT itself. Not covered in that draft is what to store in the DHT,  
but there have
been some private discussions about storing contact information for  
HIP nodes,
including Name --> HIT and HIT --> IP address mappings.

- Philip

On 1-Aug-07, at 05:55 , Samu Varjonen wrote:

> Hi,
>
> I have been meaning to write this mail for a long time, so here goes.
>
> I would like to comment and propose modifications/clarifications to
> the draft-ahrenholz-hiprg-dht-01.
>
> Re-ordering of answers from OpenDHT (multihoming).
>
> In certain conditions can the first in first out order of values under
> one key change. For example if values are put in order v1, v2 and v3,
> then v1's TTL expires before the new refreshing put is made, the v1
> will move to the end of the list of values. With more or less static
> addresses this is not a problem, because with them the refreshing put
> can take network latencies in consideration. With mobile clients and
> their frequently changing addresses it might be that the address order
> is different every time queried. This can be solved with re-ordering
> of addresses upon receiving them.
>
> Base Exchange as a requirement for publishing addresses to DHT
>
> Requiring Base Exchange to be conducted before the client can insert
> address under key (HIT) restricts the usable namespace. For example
> any put without HIP with 16-byte key starting with 2001:10/28 should
> be denied. This would effectively prevent drowning of addresses,  
> but it
> takes out 2^100 or so keys from the public use. But HIP support in
> Bamboo-DHT would need a hacked version anyway, which would possibly
> mean separate system. Question still remains is it a too big
> restriction for the keyspace in Bamboo-DHT or is it just wasting of
> good system if it is used just for resolutions and nothing else.
>
> Using LOCATOR instead of sockaddr
>
> Current draft uses sockaddr structures to save the addresses to
> OpenDHT. In most cases it is enough to categorize addresses with their
> family. NAT traversal introduces new cases, that need more
> fine-grained categorization of addresses. For example users behind a
> NAT could have multiple IPv4 addresses that belong to users RVS, relay
> or to users private LAN. Probably in most cases when users are behind
> NATs, users do not have DNS to use, and they are using OpenDHT for
> resolving purposes and would need more information on address than
> just family. On page 16 in draft-ietf-hip-nat-traversal-02-pre6, is
> defined a new LOCATOR structure that contains the address and its
> family as does the sockaddr. What makes this LOCATOR structure
> interesting is the other fields, for example preference and loc
> type. With preference the user could inform the initiator about the
> preferred address for use and with loc type the user could inform the
> initiator about RVS and relays. This could be handy when resolving
> addresses from the DHT and making the decision about which one to use,
> as in Section 2.4. in draft-ietf-hip-nat-traversal-02-pre6.
>
> BR,
>
> Samu Varjonen
> ---------------------
> samu.varjonen at hiit.fi
> samu.varjonen at helsinki.fi
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg