Subject: [Hipsec-rg] IETF 69 meeting minutes for review
From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Tue, 21 Aug 2007 07:38:03 -0700

I've posted the draft meeting minutes at the below URL:
http://www3.ietf.org/proceedings/07jul/minutes/HIPRG.txt

Barring any comments or revisions, I think that they will become final
by this Friday.

- Tom

From: miika at iki.fi (Miika Komu)
Date: Wed, 15 Aug 2007 12:21:41 +0300 (EEST)
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 9 Aug 2007, Miika Komu wrote:

Hi Jeff,

> On Mon, 6 Aug 2007, Ahrenholz, Jeffrey M wrote:
>
> Replying on multiple posts in a single mail...
>
>> 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).
>
> Yes in the sense that the OpenDHT should support same things as HIP DNS
> extensions. No in the sense that I think that DNS stuff is most useful for
> servers and OpenDHT stuff for (p2p) clients.
>
>> 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.
>
> How do you detect the most current, usable address on behalf of a remote
> host? This is not so simple especially in NATted environments.

We had some further discussions on OpenDHT with Samu: one obvious, but 
forgotten item is also IPv4-IPv6 interoperability. None of the draft 
suggests only a single locator, but should it be IPv4 or IPv6? I think 
multiple addresses in DHT would be very useful.

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

Following the DNS format could also reduce some lines of parser code if 
someone glues OpenDHT libraries to local DNS proxy software or resolver 
libraries. However, following the DNS format requires an additional lookup 
to find the RVS. According to Samu, the OpenDHT look-up latency is already 
at least twice as long as DNS in practice according to Samu.

Alternatively, we could save the few lines of parser code by reusing the 
HIP LOCATOR format. However, the mm-05 draft does not set a flag for RVS 
locators, so I guess it assumes that the RVS address is always found from 
DNS (which is not the right assumption IMHO).

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: miika at iki.fi (Miika Komu)
Date: Fri, 10 Aug 2007 09:42:09 +0300 (EEST)
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 9 Aug 2007, Henderson, Thomas R wrote:

Hi,

>> Hi,
>>
>>> Two other items I think are important to resolve are the
>> technique to
>>> avoid all of the HITs from being stored on the same server
>> due to the
>>> ORCHID prefix (this is mentioned in Jeff's draft but not really
>>> defined), and server robustness issues.
>>
>> why not just reverse the order of bits or bytes in the HIT?
>> Maybe this was
>> discussed earlier.
>
> HITs are hard enough to read forward, but backward?  (this seems
> suboptimal from an operations and debugging perspective).

Well, we can't have everything. I also suggested *byte-wise* reversing for 
slightly easier implementation.

Also DNS reverse records use a similar technique. So, it is not really 
that odd technique to reverse an address for lookup purposes.

> How about truncating the ORCHID prefix and using the Encode_100 (or
> lower 96 bits thereof)?

I don't see how this is more optimal from an operations and debugging 
perspective. If the address is not contained as it is, then it does not 
really make any difference how the address is changed.

Truncating the ORCHID prefix may have some negative effects regarding to 
address agility. Consider that there may be ORCHID2 prefix in the future 
and we want support both ORCHID and ORCHID2 prefixes for the same Host 
Identitities.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 9 Aug 2007 23:23:15 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Miika Komu [mailto:miika at iki.fi] 
> Sent: Thursday, August 09, 2007 10:45 PM
> To: Henderson, Thomas R
> Cc: Ahrenholz, Jeffrey M; hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
> 
> On Thu, 9 Aug 2007, Henderson, Thomas R wrote:
> 
> Hi,
> 
> > Two other items I think are important to resolve are the 
> technique to
> > avoid all of the HITs from being stored on the same server 
> due to the
> > ORCHID prefix (this is mentioned in Jeff's draft but not really
> > defined), and server robustness issues.
> 
> why not just reverse the order of bits or bytes in the HIT? 
> Maybe this was 
> discussed earlier.

HITs are hard enough to read forward, but backward?  (this seems
suboptimal from an operations and debugging perspective).

How about truncating the ORCHID prefix and using the Encode_100 (or
lower 96 bits thereof)?

Tom

From: miika at iki.fi (Miika Komu)
Date: Fri, 10 Aug 2007 08:44:54 +0300 (EEST)
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 9 Aug 2007, Henderson, Thomas R wrote:

Hi,

> Two other items I think are important to resolve are the technique to
> avoid all of the HITs from being stored on the same server due to the
> ORCHID prefix (this is mentioned in Jeff's draft but not really
> defined), and server robustness issues.

why not just reverse the order of bits or bytes in the HIT? Maybe this was 
discussed earlier.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 9 Aug 2007 07:58:05 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> > Maybe this draft should cover options 1-3 (or 1-2?) (with 
> mention of the
> > other options), with the goal of using OpenDHT for 
> interoperability and
> > easy deployment. I need to look at the drafts Philip referenced.
> 
> I agree that there should be a separate draft on HIP-aware OpenDHT. 
> Therefore, I'd include only options 1 and 2 in the current, "legacy" 
> opendht draft and leave rest of the options for a separate draft.
> 

I do not think it hurts to mention option 3 also because server side
signature verification is transparent to clients.  But I agree that
doing more than that starts to affect interoperability with legacy
OpenDHT servers and could be left for a separate draft.

Two other items I think are important to resolve are the technique to
avoid all of the HITs from being stored on the same server due to the
ORCHID prefix (this is mentioned in Jeff's draft but not really
defined), and server robustness issues.

For the latter, I am imagining that there will be cases where a given
host updating its own records, or an initiator trying to resolve the HIT
of the peer host, cannot reach the particular DHT server responsible for
the portion of the key space of interest.  There are a couple of
solutions that come to mind.  First, implementations could use several
well-known DHTs simultaneously (possibly some deployed by HIP research
projects).  An alternate approach for robustness within the same DHT
might be to allow a host to store its records at well-known offsets to
its primary key location (such as (key space)/2 away)-- since the DHT
key size is larger than the HIT size, this is possible.   The cost would
be additional queries into the DHT in the case where the record simply
doesn't exist in the DHT, and additional load per host on the DHT
itself.  It might be worthwhile to experiment with such a technique and
see whether it is ever useful in the field (or whether DHT availability
is good enough to obviate this), but to do so would require that the
implementations agree to populate and search an alternate key location
or alternate DHTs, and keep and share statistics on their experiences.

Tom

From: miika at iki.fi (Miika Komu)
Date: Thu, 9 Aug 2007 15:16:43 +0300 (EEST)
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 6 Aug 2007, Ahrenholz, Jeffrey M wrote:

Replying on multiple posts in a single mail...

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

Yes in the sense that the OpenDHT should support same things as HIP DNS 
extensions. No in the sense that I think that DNS stuff is most useful for 
servers and OpenDHT stuff for (p2p) clients.

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

How do you detect the most current, usable address on behalf of a remote 
host? This is not so simple especially in NATted environments.

Why not just publish all addresses (including private)? Private addresses 
have limited scope, but in a home environment it might be just enough. If 
this is not enough, just let the ICE-style probing do its magic.

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

For example, in the case you have a single, fixed-location host behind a 
NAT and you can manually punch a hole into the NAT box.

> Maybe this draft should cover options 1-3 (or 1-2?) (with mention of the
> other options), with the goal of using OpenDHT for interoperability and
> easy deployment. I need to look at the drafts Philip referenced.

I agree that there should be a separate draft on HIP-aware OpenDHT. 
Therefore, I'd include only options 1 and 2 in the current, "legacy" 
opendht draft and leave rest of the options for a separate draft.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Wed, 8 Aug 2007 08:17:44 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Samu,
I see why you were thinking about using BEX...

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

Yes, the second option of modifying the DHT server to verify signatures
is also covered in Section 3.2 of the draft.

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

So in summary of our last few emails, we have the following options:

1) normal hip-addr get/put 
   - no protection, can use OpenDHT
2) hip-secure-addr get/put w/client HIT/sig verification 
   - prevents record pollution, can use OpenDHT
3) hip-secure-addr get/put w/server HIT/sig verification 
   - prevents pollution and client flooding, must modify DHT
4) hip-secure-addr get/put over a HIP association w/server HIT
comparison
   - prevents server DoS, pollution, client flooding, response spoofing,
etc.
   - must modify DHT and run HIP
5) hip-secure-addr get/put over HIP association w/server HIT comparison,
address check using HIP/SHIM6 API
   - prevents server DoS, pollution, client flooding, response spoofing,
etc.
   - must modify DHT, run HIP, integrate with APIs

Options 1-3 are already covered in draft-ahrenholz-hiprg-dht-01. As Tom
wrote in his reply, we should sketch out some requirements.

Maybe this draft should cover options 1-3 (or 1-2?) (with mention of the
other options), with the goal of using OpenDHT for interoperability and
easy deployment. I need to look at the drafts Philip referenced.

This draft could refer to a separate, more advanced HIP-aware DHT draft,
that could deal with options 4 and 5. Maybe in the advanced draft a
subset of the HIP hosts themselves are running an integrated HIP-aware
DHT in a P2P fashion.

-Jeff

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Wed, 08 Aug 2007 10:44:35 +0300
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

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,

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

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 6 Aug 2007 16:17:55 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Miika Komu [mailto:miika at iki.fi] 
> Sent: Sunday, August 05, 2007 11:02 AM
> To: Ahrenholz, Jeffrey M
> Cc: hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
>
> P.S. Why doesn't the draft have already an official RG prefix?
> 

I do not believe that there was ever any call yet to make it a RG draft.
If there is interest, I would suggest that Jeff try to respond to the
comments with a new draft, and once published, we can discuss on this
list about making it an RG draft.  

Regarding the latest discussion, it seems to me that we ought to sketch
out some requirements for this work.  Jeff's current draft is not making
it a goal to optimize (or modify) the DHT implementation to support HIP,
but some of the discussion lately has headed that way.

Tom

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Mon, 6 Aug 2007 08:28:10 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.

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

-Jeff

From: miika at iki.fi (Miika Komu)
Date: Mon, 6 Aug 2007 11:48:31 +0300 (EEST)
Subject: [Hipsec-rg] feedback on draft-oliva-hiprg-reap4hip-00
Message-ID: <[email-masked]>

Editorial comments as scanned pages (sorry guys for the format):

http://www.iki.fi/miika/temp/draft-oliva-reap4hip-00/

Non-editorial comments:

* We should think about merging with the nat draft when the approach has
   been finally decided:
   http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt
* I disagree on the probe message format. The probe should at least be a
   normal HIP parameter. Better yet, I would suggest splitting the huge
   probe blob into multiple small parameters (real parameters or
   subparameters). These will make handling the probe easier in existing
   HIP code.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: miika at iki.fi (Miika Komu)
Date: Sun, 5 Aug 2007 21:01:59 +0300 (EEST)
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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:

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.

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/

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Wed, 1 Aug 2007 08:53:48 -0700
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Samu,
Some comments below... 

> -----Original Message-----
> From: Samu Varjonen [mailto:samu.varjonen at helsinki.fi] 
> Sent: Wednesday, August 01, 2007 2:56 AM
> To: hipsec-rg at 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.
> 

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 at hiit.fi
> samu.varjonen at helsinki.fi
> 
> 

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 1 Aug 2007 09:28:51 -0400
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Wed, 01 Aug 2007 12:55:38 +0300
Subject: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01
Message-ID: <[email-masked]>

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