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

Samu,
Some comments below...

> -----Original Message-----
> From: Samu Varjonen [mailto:samu.varjonen@helsinki.fi]
> Sent: Wednesday, August 01, 2007 2:56 AM
> To: hipsec-rg@listserv.cybertrust.com; Ahrenholz, Jeffrey M
> Subject: Some comments on draft-ahrenholz-hiprg-dht-01
>
> 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.
>

Currently the dht-01 draft has the HIP host store its preferred address in the DHT.
The idea was that if I want to send an I1 to my peer, I need to know a current address, where to send it.

Above you're discussing having multiple addresses in the DHT. Do you have some advanced multihoming situations in mind? Doesn't the current mm-05 draft consider only one preferred locator (sort of a failover multihoming)?

> 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.
>

Requiring a base exchange seems like a local policy issue. Not a bad idea, but what do you think about Section 3.2 of the dht-01 draft, where you verify each DHT put by checking that the signature, HI, and HIT match?

Performing one signature verification and one HI->HIT calculation would be easier for the server than performing a full base exchange. However, with a base exchange you would get all of the added bonuses of HIP such as encryption/authentication.

> 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.
>

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related listserv.cybertrust.com Links hipsec-rg Request more information about Pantek

Yes, this is a good point, that the sockaddr may be obsoleted by NAT and other issues.
Note that if we make the change from sockaddr to LOCATOR, and if we were concerned with storing multiple LOCATORs (as above with your multihoming comments), then we could think about storing a data blob containing a set of LOCATORs instead of just one.

-Jeff

> BR,
>
> Samu Varjonen
> ---------------------
> samu.varjonen@hiit.fi
> samu.varjonen@helsinki.fi
>
>