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

Comments on comments...

> This is supported also in the DNS extensions, so why not in
> the DHT? Is there are a need to constrain the experimentation?

It seems like you are thinking of the DHT as a DNS replacement. Without looking back at the DNS draft (RFC), I'm not sure what you would do with all of those locators returned from a query. For the DHT, I was thinking more of bootstrapping, where you have the HIT (or domain name) and you only need to find most current, usable address.

Constraint was not the intent, but rather simplicity.

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

OK, what if the DHT server is not HIP-capable? What if it's not running a native HIP/btns API? How would you enforce a uniform policy?

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.

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

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

As noted above, option (2) requires a HIP-enabled server, which I feel may be unnecessary.

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

With "hip-secure-addr" this protection already exists because the put is not accepted unless signed by the node that possesses the HI private key.

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

If you know you're behind a NAT, why not store the RVS address? We would need to adopt a format for indicating RVS (as you mentioned) such as the DNS RR format.

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

It seems like the DHT draft should just reference the HIP DNS RR format.

Do you need more 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

-Jeff