|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
Date: Sun Aug 05 2007 - 14:01:59 EDT
On Wed, 1 Aug 2007, Ahrenholz, Jeffrey M wrote:
Hi Jeff and Samu,
some comments below.
>> 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)?
Why prevent multihoming capable (server) hosts that have public IPv4/IPv6 addresses (thus no need for a single RVS address) to publish all of their locators in OpenDHT? It does not really make difference whether the purpose is failover or avoiding network congestions.
This is supported also in the DNS extensions, so why not in the DHT? Is there are a need to constrain the experimentation?
>> 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?
I think the HIT match should be enough? The DHT server code compares the HIT in the put message with the result from getpeername() function call (or whatever it is in java). The comparison should only be done with DHT puts with getpeername() returning an address with ORCHID prefix. With LSIs (or full HIs), something like this is needed:
http://www.ietf.org/internet-drafts/draft-ietf-btns-abstract-api-00.txt http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt
Depending on policies, the comparison can be mandatory, i.e., only HIP connections are allowed. Alternatively, the non-HIP connections can have less priority or ttl. One policy could be also to ignore the comparison.
Anyway, I don't think the issue is not just local. All of the ring member's need to be configured with the same policy, or otherwise an attacker will go through the ring node with least security requirements for puts.
> 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.
Seems like there are two options:
- signature verification and comparison in the DHT code
- signature verification in the HIP code and comparison in DHT code
I would do either one of them, both not both. Just too much overhead. For reasons explained below, I'd encourage thinking about option two.
I'd go a little bit further in the HIP/DHT integration. The DHT node could also check that the IP address being put matches to the one used in the base exchange. As the base exchange itself is a return routability test and optional addresses could be verified by the server using mm-draft mechanisms, we'd have the following benefits:
- I1 flooding protection (a client cannot put the IP address of another client).
- When the putting node is behind NAT, the DHT could include the public address and port of the NAT. As the stored IP address is not covered by a signature, the DHT can really do this.
The API for checking the locators is defined here:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt
I guess the downside of option 2 is bigger RTT for the *first* put/get when compared to the current draft. It is price I would be willing to pay. What do you and others think?
>> 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.
>>
>
> 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.
Independently of the NAT approach the WG is going to choose, it seems like it will require a new kind of "RVS" box. The new RVS box relays either HIP control messages or ICE control messages. I believe that there are benefits in distinguishing such middlebox addresses from the RVS addresses.
I guess the current DHT draft does even not distinguish RVS addresses from end-host addresses. This should be fixed because it is supported also in the DNS extensions. Of course, there should be "room" for new type of middleboxes that are required e.g. for NAT traversal.
P.S. Why doesn't the draft have already an official RG prefix?
-- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec-rg mailing list Hipsec-rg@listserv.cybertrust.com https://listserv.cybertrust.com/mailman/listinfo/hipsec-rgReceived on Sun Aug 5 14:02:11 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 14:16:02 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |