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

Ahrenholz, Jeffrey M wrote:
> Comments on comments...

on comments

> We don't require DNS servers to run HIP. They just need to be able to
> carry a HIP RR. In the DHT draft, I am suggesting running one hash +
> signature verification if you want some security. These are basic crypto
> functions that should be available to a system, a system that isn't
> necessarily running HIP or has access to special APIs. This approach
> takes advantage of the security properties of HIP naming.
>
> Also the DHT draft separates the two secure and insecure uses. When you
> put/get using "hip-secure-addr" you know that every server in the ring
> is performing the HI -> HIT validation, and put/get using "hip-addr"
> offers no guarantees. The "hip-addr" is immediately useful because we
> can use the (unmodified) OpenDHT nodes on PlanetLab.
>

>> Seems like there are two options:
>>
>> 1) signature verification and comparison in the DHT code
>> 2) 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

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

Yes, the address is secured with hip-secure-add, in away that it can be identified as the correct address for the HIT. But, I was rather saying with the requiring of BEX that it would stop the flooding of the key. Like, if a malicious user knows your HIT he could continuously just put   bogus information under your HIT and then the work for finding the right value could proof to be hard for a client.

Protection for this could be done with modifications to the DHT code to make it HIP enabled or then just check the signature in put msg. The second one is actually mentioned in

OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005

but is named as signed puts (on todo list if I remember correctly, but haven't seen anything new in a long time from bamboo camp). Both of these approaches need modifications to bamboo code. Requiring BEX would offer some extra benefits like DoS prevention stuff. If DHT just checked the signature for every packet it would be easier for malicious users to get the DHT to do useless checks of msgs, but when requiring BEX it would at least slow them down.

BR,

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

Samu Varjonen
.-.-.-.-.-.-.-.-.-.-.
samu.varjonen@hiit.fi