Subject: [Hipsec-rg] Garbage-collecting LSIs?
From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Thu, 27 Dec 2007 19:43:37 +0200

>>> Practically speaking, is 1/8 likely to be allocated to the RIRs?  
>>> If so, should we pick another range that is less likely to be  
>>> allocated (in the absence of getting the formal approval)?
>>>
>>> Maybe someone else on the list has more background about whether  
>>> IANA would even consider what we are talking about formalizing,  
>>> or maybe we should take this question to another list.
>>
>> Maybe the right answer is to progress a short document through the  
>> HIP RG or HIP WG trying to allocate 1/8 for this purpose and see  
>> what happens?
>
> IAB and IESG are trying to figure out what to do with 240/4 - the  
> problem is (1) this address range has lots of IPv4 addresses, but  
> (2) probably isn't routable on the global Internet because it's  
> been reserved since, like, forever.
>
> If you're going to go there (requesting a large IPv4 allocation for  
> LSIs, but the allocation doesn't have to be routable), you might  
> start with a request to allocate part of 240/4.
>
> One proposal is at http://www.ietf.org/internet-drafts/draft- 
> fuller-240space-00.txt, so this is
> a good time to talk about possible uses.

I would like to encourage others to take a look at this.   
Unfortunately I expect the process related to 240/4 will be so  
political and full of unfounded or badly founded opinions that I  
cannot make myself to personally bother about the issue.

Personally, I would expect IPv4 LSIs to be more widely used only with  
legacy applications, and I expect the great majority of legacy  
applications being ones that are used only internally within  
organisations.  For such scenarios, manual management of the LSI  
space should be manageable; I could even imagine one of the RFC1918  
spaces to be used within a company for such a purpose.

But, obviously, people's opinions differ here.  Hence, those that  
believe that IPv4 LSIs would be needed in the wider Internet should  
IMHO consider writing a draft of something about the 240 space.

--Pekka

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 26 Dec 2007 11:28:26 -0600
Subject: [Hipsec-rg] Garbage-collecting LSIs?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I replied privately, and Philip asked me why I hadn't sent this to the list, 
sooo...

>> Practically speaking, is 1/8 likely to be allocated to the RIRs?
>> If so,
>> should we pick another range that is less likely to be allocated
>> (in the
>> absence of getting the formal approval)?
>>
>> Maybe someone else on the list has more background about whether IANA
>> would even consider what we are talking about formalizing, or maybe we
>> should take this question to another list.
>
> Maybe the right answer is to progress a short document through the
> HIP RG or HIP WG trying to allocate 1/8 for this purpose and see what
> happens?

IAB and IESG are trying to figure out what to do with 240/4 - the
problem is (1) this address range has lots of IPv4 addresses, but (2) 
probably isn't routable on the global Internet because it's been reserved 
since, like, forever.

If you're going to go there (requesting a large IPv4 allocation for LSIs, 
but the allocation doesn't have to be routable), you might start with a 
request to allocate part of 240/4.

One proposal is at 
http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt, so this is 
a good time to talk about possible uses.

(Unless one or more ADs quickly explains why this is a dumb idea)...

Thanks,

Spencer

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 21 Dec 2007 08:41:51 -0500
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 20-Dec-07, at 17:46 , Henderson, Thomas R wrote:

>
>
>> -----Original Message-----
>> From: Philip Matthews [mailto:philip_matthews at magma.ca]
>> Sent: Thursday, December 20, 2007 10:10 AM
>> To: Henderson, Thomas R
>> Cc: Pekka Nikander; hipsec-rg at listserv.cybertrust.com
>> Subject: Re: [Hipsec-rg] Garbage-collecting LSIs?
>>
>>
>> On 20-Dec-07, at 12:15 , Henderson, Thomas R wrote:
>>>
>>> There is no automated duplicate LSI (collision) detection,
>> although
>>> this
>>> would be fairly trivial to add.
>>
>> What would you do if there was a collision? Not allocate an LSI, and
>> thus return failure? Or try to allocate an unused LSI? As
>> soon as you
>> start doing the latter, you get into the questions that I am
>> driving at.
>
> I had a few responses but then thought I'd better ask more about your
> operating assumptions:
> - how many HIP hosts will the implementation need to be talking to in
> practice (tens, hundreds, thousands)?
I am assuming 10s to 100s at one time, and perhaps 1000s to 10000s  
over its lifetime (between reboots).
For ordinary desktop or laptop machines, these numbers seem  
reasonable to me.
For a web-server or similar, these numbers are too low.

> - what are the assumptions on applications caching these descriptors?
This is a VERY good question.
I am going to assume that applications will not cache these  
descriptors (without actively sending packets to them) for more than  
24 hours or so.

> - how do you perceive that applications learn the LSIs?  Always  
> through
> the resolver, or through their own means (such as forming them out of
> the HIT themselves)?
Always through the resolver.

>
>>
>>> I am skeptical that it would be allocated in the current
>> environment.
>>> However, I think it would be a good idea to have a /8
>> allocated for
>>> use
>>> in IPv4 overlays in general, just so if these "addresses"
>> showed up in
>>> logs, someone reading the logs could understand better what
>> they mean.
>>
>> I agree that the /8 doesn't have to be restricted to just HIP.
>> However, I am wondering if a /8 would be allocated at all.
>>
>>> I don't think the lack of formal allocation is really a hindrance to
>>> wider-scale adoption of HIP in practice, since these are locally
>>> scoped
>>> identifiers (i.e., only within the host).
>>
>> But if IANA allocates 1/8 to the RIRs for allocation to users, then
>> any nodes using these as LSIs would be in trouble.  Thus I think a
>> formal allocation is needed.
>>
>
> Practically speaking, is 1/8 likely to be allocated to the RIRs?   
> If so,
> should we pick another range that is less likely to be allocated  
> (in the
> absence of getting the formal approval)?
>
> Maybe someone else on the list has more background about whether IANA
> would even consider what we are talking about formalizing, or maybe we
> should take this question to another list.

Maybe the right answer is to progress a short document through the  
HIP RG or HIP WG trying to allocate 1/8 for this purpose and see what  
happens?

- Philip

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 20 Dec 2007 14:46:07 -0800
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews at magma.ca] 
> Sent: Thursday, December 20, 2007 10:10 AM
> To: Henderson, Thomas R
> Cc: Pekka Nikander; hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] Garbage-collecting LSIs?
> 
> 
> On 20-Dec-07, at 12:15 , Henderson, Thomas R wrote:
> >
> > There is no automated duplicate LSI (collision) detection, 
> although  
> > this
> > would be fairly trivial to add.
> 
> What would you do if there was a collision? Not allocate an LSI, and  
> thus return failure? Or try to allocate an unused LSI? As 
> soon as you  
> start doing the latter, you get into the questions that I am 
> driving at.

I had a few responses but then thought I'd better ask more about your
operating assumptions:
- how many HIP hosts will the implementation need to be talking to in
practice (tens, hundreds, thousands)?
- what are the assumptions on applications caching these descriptors?
- how do you perceive that applications learn the LSIs?  Always through
the resolver, or through their own means (such as forming them out of
the HIT themselves)?

> 
> > I am skeptical that it would be allocated in the current 
> environment.
> > However, I think it would be a good idea to have a /8 
> allocated for  
> > use
> > in IPv4 overlays in general, just so if these "addresses" 
> showed up in
> > logs, someone reading the logs could understand better what 
> they mean.
> 
> I agree that the /8 doesn't have to be restricted to just HIP.
> However, I am wondering if a /8 would be allocated at all.
> 
> > I don't think the lack of formal allocation is really a hindrance to
> > wider-scale adoption of HIP in practice, since these are locally  
> > scoped
> > identifiers (i.e., only within the host).
> 
> But if IANA allocates 1/8 to the RIRs for allocation to users, then  
> any nodes using these as LSIs would be in trouble.  Thus I think a  
> formal allocation is needed.
> 

Practically speaking, is 1/8 likely to be allocated to the RIRs?  If so,
should we pick another range that is less likely to be allocated (in the
absence of getting the formal approval)?

Maybe someone else on the list has more background about whether IANA
would even consider what we are talking about formalizing, or maybe we
should take this question to another list.  

Tom

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 20 Dec 2007 13:10:25 -0500
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 20-Dec-07, at 12:15 , Henderson, Thomas R wrote:
>
> There is no automated duplicate LSI (collision) detection, although  
> this
> would be fairly trivial to add.

What would you do if there was a collision? Not allocate an LSI, and  
thus return failure? Or try to allocate an unused LSI? As soon as you  
start doing the latter, you get into the questions that I am driving at.

> I am skeptical that it would be allocated in the current environment.
> However, I think it would be a good idea to have a /8 allocated for  
> use
> in IPv4 overlays in general, just so if these "addresses" showed up in
> logs, someone reading the logs could understand better what they mean.

I agree that the /8 doesn't have to be restricted to just HIP.
However, I am wondering if a /8 would be allocated at all.

> I don't think the lack of formal allocation is really a hindrance to
> wider-scale adoption of HIP in practice, since these are locally  
> scoped
> identifiers (i.e., only within the host).

But if IANA allocates 1/8 to the RIRs for allocation to users, then  
any nodes using these as LSIs would be in trouble.  Thus I think a  
formal allocation is needed.

- Philip

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 20 Dec 2007 09:35:02 -0800
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews at magma.ca] 
> Sent: Thursday, December 20, 2007 5:40 AM
> To: Pekka Nikander
> Cc: hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] Garbage-collecting LSIs?
> 
> Pekka:
> 
> Thanks for the info.
> Your observation about the HIP4BSD implementation brings up a 
> related  
> point about the space for the IPv4 LSI.
> 
> Right now, I understand that the 1/8 space is being used in 
> all three  
> implementations, which is currently marked as "reserved" by IANA.  
> While this is sufficient for research purposes, I think this is not  
> sufficient for production use.
> 
> Do people really think that a whole /8 would be allocated to HIP in  
> the current IPv4 address crunch situation? It seems to be that a /16  
> is more likely. This suggests that HIP4BSD strategy is a bit  
> questionable, since collisions would be more likely.

I am skeptical that it would be allocated in the current environment.
However, I think it would be a good idea to have a /8 allocated for use
in IPv4 overlays in general, just so if these "addresses" showed up in
logs, someone reading the logs could understand better what they mean.

I don't think the lack of formal allocation is really a hindrance to
wider-scale adoption of HIP in practice, since these are locally scoped
identifiers (i.e., only within the host).

Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 20 Dec 2007 09:15:15 -0800
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander at nomadiclab.com] 
> Sent: Wednesday, December 19, 2007 8:22 PM
> To: Philip Matthews
> Cc: hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] Garbage-collecting LSIs?
> 
> The implementers can obviously give a more accurate answer, 
> but alas,  
> my understanding of the situation is as follows:
> 
> 1. In HIP4BSD implementation, the low order 24 bits of an LSI are  
> identical to those of HITs.  I don't think there is any code for  
> collisions, or if there is, it hasn't been fully tested.
> 
> 2. In the OpenHIP implementation, LSIs must be configured by hand.

In OpenHIP, the default LSI is assigned within the 1.0.0.0/8 prefix as
the low order 24 HIT bits, just as in HIP4BSD.  However, a user is free
to override those to provide more convenient values such as 1.0.0.1, by
later editing the known hosts file by hand.

There is no automated duplicate LSI (collision) detection, although this
would be fairly trivial to add.

Tom

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 20 Dec 2007 08:39:32 -0500
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Pekka:

Thanks for the info.
Your observation about the HIP4BSD implementation brings up a related  
point about the space for the IPv4 LSI.

Right now, I understand that the 1/8 space is being used in all three  
implementations, which is currently marked as "reserved" by IANA.  
While this is sufficient for research purposes, I think this is not  
sufficient for production use.

Do people really think that a whole /8 would be allocated to HIP in  
the current IPv4 address crunch situation? It seems to be that a /16  
is more likely. This suggests that HIP4BSD strategy is a bit  
questionable, since collisions would be more likely.

- Philip

On 19-Dec-07, at 23:21 , Pekka Nikander wrote:

> The implementers can obviously give a more accurate answer, but  
> alas, my understanding of the situation is as follows:
>
> 1. In HIP4BSD implementation, the low order 24 bits of an LSI are  
> identical to those of HITs.  I don't think there is any code for  
> collisions, or if there is, it hasn't been fully tested.
>
> 2. In the OpenHIP implementation, LSIs must be configured by hand.
>
> 3. In the HIPL implementation, there was no LSI support at all last  
> time I checked.  I don't know about the situation today.
>
> --Pekka Nikander
>
>
> On 20 Dec 2007, at 00:28, Philip Matthews wrote:
>
>> Since there is a limited IPv4 LSI space, I am just wondering what
>> algorithms current HIP implementations use to recover previously used
>> LSIs and recycle them for re-use?   Do any implementations handle
>> this problem?
>>
>> - Philip
>>
>> _______________________________________________
>> Hipsec-rg mailing list
>> Hipsec-rg at listserv.cybertrust.com
>> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>>
>
>

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Thu, 20 Dec 2007 06:21:47 +0200
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The implementers can obviously give a more accurate answer, but alas,  
my understanding of the situation is as follows:

1. In HIP4BSD implementation, the low order 24 bits of an LSI are  
identical to those of HITs.  I don't think there is any code for  
collisions, or if there is, it hasn't been fully tested.

2. In the OpenHIP implementation, LSIs must be configured by hand.

3. In the HIPL implementation, there was no LSI support at all last  
time I checked.  I don't know about the situation today.

--Pekka Nikander

On 20 Dec 2007, at 00:28, Philip Matthews wrote:

> Since there is a limited IPv4 LSI space, I am just wondering what
> algorithms current HIP implementations use to recover previously used
> LSIs and recycle them for re-use?   Do any implementations handle
> this problem?
>
> - Philip
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 19 Dec 2007 17:28:52 -0500
Subject: [Hipsec-rg] Garbage-collecting LSIs?
Message-ID: <[email-masked]>

Since there is a limited IPv4 LSI space, I am just wondering what  
algorithms current HIP implementations use to recover previously used  
LSIs and recycle them for re-use?   Do any implementations handle  
this problem?

- Philip

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 18 Dec 2007 13:26:14 -0500
Subject: [Hipsec-rg] rationale for HIP in P2PSIP design
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 18-Dec-07, at 11:50 , Henderson, Thomas R wrote:

>>
> Philip,
>
> I think we have overlap with the #1,2,4 items of my list:
>
>>
>> 1) Allow legacy applications to operate in an overlay;
>
> this is basically my #4
>
>>
>> 2) Allow NAT Traversal to be handled in a single place, rather than
>> in every application;
>
> this is another aspect of my #4
>
Just a comment that, based on my experience talking with others, I  
suggest we break out my (1) and (2) as separate items, as I see them  
as being the biggest benefits.

>>
>> 3) Allow peers to maintain connections while being mobile;
>
> this is basically my #1
>
>>
>> 4) Encrypt messages between peers (same as Tom's #2)
>>
>>
>
>>
>>>
>>> 3) protect public servers from certain types of DoS attacks, as
>>> protected by the HIP base exchange
>>
>> Err...
>> First of all, the servers must be part of the overlay,
>> otherwise this
>> is not really relevant to P2PSIP.
>>
> Yes, I am saying that there are going to be "servers" (perhaps  
> everyone
> can be considered a server in P2P, from HIP perspective) that can be
> protected by resource depletion attacks, if they care to use the  
> cookie
> mechanisms, or implement ACLs and check HMACs in the messages.
>
>> But more seriously, I don't think we really understand DoS attacks
>> yet in a P2P overlay.
>
> Yes, that is why I was saying it might be a possible benefit, but I
> don't know whether it is a requirement yet.  It seems to me that it
> might be a useful feature for any servers such as enrollment servers
> that might be susceptible to the kind of DoS attacks that happen to
> hosting providers or their DNS servers nowadays.

Perhaps just say that the HIP Base Exchange protects against certain  
types of DoS attacks, and this might be useful in a P2P overlay but  
that more investigation is required to make sure?

>
>>
>>>
>>> 4) provide a mobile, NAT-traversing substrate layer that allows apps
>>> (P2PSIP-based and others) to bind legacy sockets to fixed
>> identifiers
>>>
>>> 5) secure the flat identifiers (peer-IDs) in the system when there
>>> is no
>>> central authority present
>>
>> Maybe.
>> Eric Rescorla has pointed out problems with the naive way of doing
>> this, so I am not sure that we have solved this problem yet.
>
> I understand this attack.  I am not sure it is applicable in all
> scenarios, such as the ad hoc, unmanaged deployments I am thinking of.
> It may be that there are additional byzantine procedures that are  
> needed
> to handle overlay routing problems in such a case, but it seems to me
> that it is reasonable to consider the use of HITs as peer-IDs when  
> there
> is no central server to allocate them or to rate-limit their  
> generation.

You may be right. I, at least, don't have any other ideas how to  
solve this problem.

- Philip

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Tue, 18 Dec 2007 08:50:48 -0800
Subject: [Hipsec-rg] rationale for HIP in P2PSIP design
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews at magma.ca] 
> Sent: Monday, December 17, 2007 7:11 PM
> To: Henderson, Thomas R
> Cc: hipsec-rg at listserv.cybertrust.com
> Subject: Re: [Hipsec-rg] rationale for HIP in P2PSIP design
> 
> Let me respond with my own list, which is somewhat different 
> from Tom's.
> 
> But before I do, I think it is important to point out that what I am  
> talking about is not pure HIP, but HIP (or something like it) 
> used in  
> one of the ways proposed in either HIP-HOP, WITH-HIP, or ID-LOC, all  
> of which add the notion of an overlay in someway or another to the  
> use of HIP.
> 
> With that caveat, here is my list:

Philip,

I think we have overlap with the #1,2,4 items of my list:

> 
> 1) Allow legacy applications to operate in an overlay;

this is basically my #4

> 
> 2) Allow NAT Traversal to be handled in a single place, rather than  
> in every application;

this is another aspect of my #4

> 
> 3) Allow peers to maintain connections while being mobile;

this is basically my #1

> 
> 4) Encrypt messages between peers (same as Tom's #2)
> 
> 

> 
> >
> > 3) protect public servers from certain types of DoS attacks, as
> > protected by the HIP base exchange
> 
> Err...
> First of all, the servers must be part of the overlay, 
> otherwise this  
> is not really relevant to P2PSIP.
> 
Yes, I am saying that there are going to be "servers" (perhaps everyone
can be considered a server in P2P, from HIP perspective) that can be
protected by resource depletion attacks, if they care to use the cookie
mechanisms, or implement ACLs and check HMACs in the messages.  

> But more seriously, I don't think we really understand DoS attacks  
> yet in a P2P overlay.

Yes, that is why I was saying it might be a possible benefit, but I
don't know whether it is a requirement yet.  It seems to me that it
might be a useful feature for any servers such as enrollment servers
that might be susceptible to the kind of DoS attacks that happen to
hosting providers or their DNS servers nowadays.

> 
> >
> > 4) provide a mobile, NAT-traversing substrate layer that allows apps
> > (P2PSIP-based and others) to bind legacy sockets to fixed 
> identifiers
> >
> > 5) secure the flat identifiers (peer-IDs) in the system when there  
> > is no
> > central authority present
> 
> Maybe.
> Eric Rescorla has pointed out problems with the naive way of doing  
> this, so I am not sure that we have solved this problem yet.

I understand this attack.  I am not sure it is applicable in all
scenarios, such as the ad hoc, unmanaged deployments I am thinking of.
It may be that there are additional byzantine procedures that are needed
to handle overlay routing problems in such a case, but it seems to me
that it is reasonable to consider the use of HITs as peer-IDs when there
is no central server to allocate them or to rate-limit their generation.

Tom

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 17 Dec 2007 22:10:42 -0500
Subject: [Hipsec-rg] rationale for HIP in P2PSIP design
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Let me respond with my own list, which is somewhat different from Tom's.

But before I do, I think it is important to point out that what I am  
talking about is not pure HIP, but HIP (or something like it) used in  
one of the ways proposed in either HIP-HOP, WITH-HIP, or ID-LOC, all  
of which add the notion of an overlay in someway or another to the  
use of HIP.

With that caveat, here is my list:

1) Allow legacy applications to operate in an overlay;

2) Allow NAT Traversal to be handled in a single place, rather than  
in every application;

3) Allow peers to maintain connections while being mobile;

4) Encrypt messages between peers (same as Tom's #2)

Some comments on Tom's list below.

- Philip

On 17-Dec-07, at 19:09 , Henderson, Thomas R wrote:

> One of the outcomes of the informal Friday morning meeting in  
> Vancouver
> between HIP and P2PSIP participants was that we agreed that the HIP
> community should try to summarize a brief overview of HIP and why it
> might be of interest to P2PSIP.
>
> Gonzalo has agreed to collect and summarize these views, but I thought
> we could start by listing possible reasons that HIP might be  
> considered
> as part of the P2PSIP solution.
>
> It might also be nice to indicate where there is published work that
> validates the below hypotheses, since there has been some  
> questioning of
> some of these claims on the P2PSIP mailing list.
>
> Let me start this discussion by pasting and slightly expanding on a  
> list
> I posted last week.
>
> Possible reasons for using HIP in P2PSIP design
> ==================
>
> 1) secure the media sessions (using ESP or SRTP) between application
> endpoints and support their locator agility (possibly also by  
> providing
> secure channel bindings that reduce the security protocol requirements
> of higher layers)
>
> 2) secure the communications between nodes in the control plane of
> P2PSIP (clients, peers, enrollment servers)

Just the control plane messages?
Why not also, for example, RTP traffic?

>
> 3) protect public servers from certain types of DoS attacks, as
> protected by the HIP base exchange

Err...
First of all, the servers must be part of the overlay, otherwise this  
is not really relevant to P2PSIP.

But more seriously, I don't think we really understand DoS attacks  
yet in a P2P overlay.

>
> 4) provide a mobile, NAT-traversing substrate layer that allows apps
> (P2PSIP-based and others) to bind legacy sockets to fixed identifiers
>
> 5) secure the flat identifiers (peer-IDs) in the system when there  
> is no
> central authority present

Maybe.
Eric Rescorla has pointed out problems with the naive way of doing  
this, so I am not sure that we have solved this problem yet.

>
> Please respond by discussing, extending, or arguing against the above,
> and possibly by stating which of the above are the strongest  
> rationales
> for HIP, in your opinion.
>
> - Tom
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 17 Dec 2007 16:09:26 -0800
Subject: [Hipsec-rg] rationale for HIP in P2PSIP design
Message-ID: <[email-masked]>

One of the outcomes of the informal Friday morning meeting in Vancouver
between HIP and P2PSIP participants was that we agreed that the HIP
community should try to summarize a brief overview of HIP and why it
might be of interest to P2PSIP.

Gonzalo has agreed to collect and summarize these views, but I thought
we could start by listing possible reasons that HIP might be considered
as part of the P2PSIP solution.

It might also be nice to indicate where there is published work that
validates the below hypotheses, since there has been some questioning of
some of these claims on the P2PSIP mailing list.

Let me start this discussion by pasting and slightly expanding on a list
I posted last week.  

Possible reasons for using HIP in P2PSIP design
==================

1) secure the media sessions (using ESP or SRTP) between application
endpoints and support their locator agility (possibly also by providing
secure channel bindings that reduce the security protocol requirements
of higher layers)

2) secure the communications between nodes in the control plane of
P2PSIP (clients, peers, enrollment servers)

3) protect public servers from certain types of DoS attacks, as
protected by the HIP base exchange 

4) provide a mobile, NAT-traversing substrate layer that allows apps
(P2PSIP-based and others) to bind legacy sockets to fixed identifiers

5) secure the flat identifiers (peer-IDs) in the system when there is no
central authority present

Please respond by discussing, extending, or arguing against the above,
and possibly by stating which of the above are the strongest rationales
for HIP, in your opinion.

- Tom

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 14 Dec 2007 13:27:18 -0500
Subject: [Hipsec-rg] HIP for P2PSIP: the proposals
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 14-Dec-07, at 01:43 , Henderson, Thomas R wrote:

>
>
>> -----Original Message-----
>> From: Philip Matthews [mailto:philip_matthews at magma.ca]
>> Sent: Thursday, December 13, 2007 1:28 PM
>> To: hipsec-rg at listserv.cybertrust.com
>> Subject: [Hipsec-rg] HIP for P2PSIP: the proposals
>>
>> Let me give a brief description of how I see the three HIP-based
>> proposals currently proposed for P2PSIP.
>>
>> draft-matthews-p2psip-hip-hop:     HIP lies below the Peer Protocol.
>> HIP is extended with overlay routing.
>>
>> draft-hautakorpi-p2psip-with-hip:  HIP lies above the Peer Protocol.
>> No HIP extensions proposed.
>>
>> draft-matthews-p2psip-id-loc:      Some of the concepts from HIP are
>> integrated into the Peer Protocol. HIP (the signaling protocol) is
>> not used.
>>
>>
>> Let me now argue a bit for the third approach. [The thinking here is
>> new, and is not given in the current draft].
>> With the approach given in the third proposal, I am now
>> thinking that
>> HIP (the signaling protocol) is used for setting up connections
>> between two nodes when they ARE NOT in an overlay, while the P2PSIP
>> Peer Protocol is used for setting up connections between two nodes
>> when they ARE in an overlay.
>>
>> In other words, HIP and the Peer Protocol would be complementary:
>> they do the same thing, but one is used in some situations while the
>> other is used in other situations.
>>
>> Comments?
>>
>
> Philip,
>
> I am not sure I understand enough of your latest rationale, because  
> you
> seem to compare HIP signaling (base exchange?) with the Peer Protocol
> but these are protocols doing different things.  Or are you talking
> about overlay routing the end-to-end signaling in either case (with  
> HIP
> over a HIP overlay vs. with Peer Protocol over the peer overlay)?

What I meant was "add features of HIP to the Peer Protocol and then
use the Peer Protocol in overlay situations, and HIP in non-overlay
situations". The two protocols would share the same data plane.

This gives the following signaling stack:
+-------------+---------------------+
|    HIP      |   Peer Protocol     |
+-------------+---------------------+
|       Transport layer             |
+-----------------------------------+
|             IP                    |
+-----------------------------------+
If HIP eventually moves back to run over IP directly, then the Peer  
Protocol
might do the same.

And the following data plane stack:
+-----------------------------------+
|         Application               |
+-----------------------------------+
|         Transport Layer           |
+-----------------------------------+
|         ESP or other              |
+-----------------------------------+
|             IP                    |
+-----------------------------------+

>
> Here are some possible motivations for using HIP as part of P2PSIP
> solution:
> 1) secure the media sessions and support their locator agility
> 2) protect public servers from certain types of DoS attacks
> 3) provide a mobile, NAT-traversing substrate layer that allows apps
> (P2PSIP and others) to bind legacy sockets to fixed identifiers
> 4) secure the flat identifiers (peer-IDs) in the system when there  
> is no
> central authority present
>
> 2) has not gotten much discussion; I'm not sure it is considered a
> P2PSIP requirement.  As for 1) there have been requests on the P2PSIP
> list to show quantitatively that HIP makes a difference.  3) and 4)  
> are
> very useful IMO, but 3) is still in conceptual phase, and 4) has been
> declared a non-goal (charter-wise) by the P2PSIP group.

The ID-LOC proposal brings (1) and (3) to the Peer Protocol.
It is not clear what (2) means in a P2P overlay.
For (4), I now think I want to make peer IDs distinct from HITs.

>
> Now considering deployment, HIP is not deployed, so P2PSIP  
> applications
> would need to install it (if not already installed) to run  
> ubiquitously
> on it.  If that is the deployment plan, then I think that HIP better
> provide evidence that its solutions to the above motivations are
> discriminators.
>
> A solution that would appeal to me as I write this now would have the
> following elements:
>
> - P2PSIP does not have any HIP dependencies or requirements; however,
> support for running over or with HIP is defined into the P2PSIP  
> solution
> in a forward-compatible way
>
> - for a given overlay deployment, P2PSIP can optionally use HIP
> identifiers (ORCHIDs) in place of IP addresses in contact URIs and  
> where
> DNS resolution is used.  The overlay that resolves contact URIs to
> ORCHIDs also resolves ORCHIDs to locators.
>   * to support this, the application may itself want to deploy HIP as
> part of its install process to populate it throughout the overlay,
> although in a heterogeneous client population, it is not guaranteed to
> be on every node
>   * since HIP is not guaranteed to be there, there has to be a  
> fallback
> path to non-HIP, which suggests that Contact URIs with HITs in them
> should be used in parallel to the ones with IP addresses in them
>
> - if HIP is deployed, P2PSIP can use the base exchange, by policy
> choice, for either overlay connection signaling or peer-to-peer media
> session protection
>   * and HIP WG defines other P2P-friendly transport formats
>
> - if P2PSIP operates in an ad hoc or disconnected mode, HIP  
> identifiers
> can be used as peer-IDs (when there is no central enrollment server)
>
> - P2PSIP/HIP combination, when deployed, offers support to all
> applications
>
> In the above scenario, HIP will deploy and start to be used if/when
> benefits outweigh the costs of the additional namespace in the system,
> and once it deploys, it can start to be used more broadly than P2PSIP,
> which could be thought of as a bootstrapping deployment for HIP also.
>
> So in some sense, I think the above description gravitates towards  
> your
> thoughts of porting ideas from HIP into P2PSIP, although I would also
> try to ensure that we have forward compatibility with potential HIP
> deployment.

I have heard something similar to your ideas above. However, my  
personal preference is to come up with a scheme that is attractive  
enough to make it ALWAYS a part of the P2PSIP standard. I am hoping  
that ID-LOC might be that scheme.

- Philip

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 13 Dec 2007 22:43:55 -0800
Subject: [Hipsec-rg] HIP for P2PSIP: the proposals
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews at magma.ca] 
> Sent: Thursday, December 13, 2007 1:28 PM
> To: hipsec-rg at listserv.cybertrust.com
> Subject: [Hipsec-rg] HIP for P2PSIP: the proposals
> 
> Let me give a brief description of how I see the three HIP-based  
> proposals currently proposed for P2PSIP.
> 
> draft-matthews-p2psip-hip-hop:     HIP lies below the Peer Protocol.  
> HIP is extended with overlay routing.
> 
> draft-hautakorpi-p2psip-with-hip:  HIP lies above the Peer Protocol.  
> No HIP extensions proposed.
> 
> draft-matthews-p2psip-id-loc:      Some of the concepts from HIP are  
> integrated into the Peer Protocol. HIP (the signaling protocol) is  
> not used.
> 
> 
> Let me now argue a bit for the third approach. [The thinking here is  
> new, and is not given in the current draft].
> With the approach given in the third proposal, I am now 
> thinking that  
> HIP (the signaling protocol) is used for setting up connections  
> between two nodes when they ARE NOT in an overlay, while the P2PSIP  
> Peer Protocol is used for setting up connections between two nodes  
> when they ARE in an overlay.
> 
> In other words, HIP and the Peer Protocol would be complementary:  
> they do the same thing, but one is used in some situations while the  
> other is used in other situations.
> 
> Comments?
> 

Philip,

I am not sure I understand enough of your latest rationale, because you
seem to compare HIP signaling (base exchange?) with the Peer Protocol
but these are protocols doing different things.  Or are you talking
about overlay routing the end-to-end signaling in either case (with HIP
over a HIP overlay vs. with Peer Protocol over the peer overlay)?

Here are some possible motivations for using HIP as part of P2PSIP
solution:
1) secure the media sessions and support their locator agility
2) protect public servers from certain types of DoS attacks
3) provide a mobile, NAT-traversing substrate layer that allows apps
(P2PSIP and others) to bind legacy sockets to fixed identifiers
4) secure the flat identifiers (peer-IDs) in the system when there is no
central authority present

2) has not gotten much discussion; I'm not sure it is considered a
P2PSIP requirement.  As for 1) there have been requests on the P2PSIP
list to show quantitatively that HIP makes a difference.  3) and 4) are
very useful IMO, but 3) is still in conceptual phase, and 4) has been
declared a non-goal (charter-wise) by the P2PSIP group.

Now considering deployment, HIP is not deployed, so P2PSIP applications
would need to install it (if not already installed) to run ubiquitously
on it.  If that is the deployment plan, then I think that HIP better
provide evidence that its solutions to the above motivations are
discriminators.

A solution that would appeal to me as I write this now would have the
following elements:

- P2PSIP does not have any HIP dependencies or requirements; however,
support for running over or with HIP is defined into the P2PSIP solution
in a forward-compatible way

- for a given overlay deployment, P2PSIP can optionally use HIP
identifiers (ORCHIDs) in place of IP addresses in contact URIs and where
DNS resolution is used.  The overlay that resolves contact URIs to
ORCHIDs also resolves ORCHIDs to locators.
  * to support this, the application may itself want to deploy HIP as
part of its install process to populate it throughout the overlay,
although in a heterogeneous client population, it is not guaranteed to
be on every node
  * since HIP is not guaranteed to be there, there has to be a fallback
path to non-HIP, which suggests that Contact URIs with HITs in them
should be used in parallel to the ones with IP addresses in them

- if HIP is deployed, P2PSIP can use the base exchange, by policy
choice, for either overlay connection signaling or peer-to-peer media
session protection
  * and HIP WG defines other P2P-friendly transport formats

- if P2PSIP operates in an ad hoc or disconnected mode, HIP identifiers
can be used as peer-IDs (when there is no central enrollment server) 

- P2PSIP/HIP combination, when deployed, offers support to all
applications

In the above scenario, HIP will deploy and start to be used if/when
benefits outweigh the costs of the additional namespace in the system,
and once it deploys, it can start to be used more broadly than P2PSIP,
which could be thought of as a bootstrapping deployment for HIP also.

So in some sense, I think the above description gravitates towards your
thoughts of porting ideas from HIP into P2PSIP, although I would also
try to ensure that we have forward compatibility with potential HIP
deployment.

Tom

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 13 Dec 2007 16:28:13 -0500
Subject: [Hipsec-rg] HIP for P2PSIP: the proposals
Message-ID: <[email-masked]>

Let me give a brief description of how I see the three HIP-based  
proposals currently proposed for P2PSIP.

draft-matthews-p2psip-hip-hop:     HIP lies below the Peer Protocol.  
HIP is extended with overlay routing.

draft-hautakorpi-p2psip-with-hip:  HIP lies above the Peer Protocol.  
No HIP extensions proposed.

draft-matthews-p2psip-id-loc:      Some of the concepts from HIP are  
integrated into the Peer Protocol. HIP (the signaling protocol) is  
not used.

Let me now argue a bit for the third approach. [The thinking here is  
new, and is not given in the current draft].
With the approach given in the third proposal, I am now thinking that  
HIP (the signaling protocol) is used for setting up connections  
between two nodes when they ARE NOT in an overlay, while the P2PSIP  
Peer Protocol is used for setting up connections between two nodes  
when they ARE in an overlay.

In other words, HIP and the Peer Protocol would be complementary:  
they do the same thing, but one is used in some situations while the  
other is used in other situations.

Comments?

- Philip

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Thu, 13 Dec 2007 09:19:14 -0800
Subject: [Hipsec-rg] Proposing a new packet type for resolving purposes(draft-ahrenholz-hiprg-dht-01)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Samu, 

> -----Original Message-----
> From: Samu Varjonen [mailto:samu.varjonen at helsinki.fi] 
> Sent: Thursday, December 13, 2007 3:33 AM
> To: hipsec-rg at listserv.cybertrust.com
> Subject: [Hipsec-rg] Proposing a new packet type for 
> resolving purposes(draft-ahrenholz-hiprg-dht-01)
> 
> Hi,
> 
> I am proposing a change in the way addresses are handled in HIP DHT 
> interface draft.
> 
> Currently the 01 suggests to use sockaddrs when storing addresses to 
> OpenDHT. And on multihoming cases this leads to case where every IP is

> considered as a different value under one key. OpenDHTs accepts only
one 
> put per connection and then it closes the connection. This leads to 
> multiple connection establishments, when client has multiple
addresses. 
> While all addresses and some other information could be sent in more 
> convenient way. This has been discussed on the list previously and
then 
> I suggested the usage of LOCATOR parameter.

To resurrect our old discussion (Aug 07), someone also suggested using
the HIP DNS RR format, so that RVS addresses would be supported. But I'd
agree to use the LOCATOR since it will be easier to implement with
existing HIP code, and you could support the new NAT LOCATOR
modifications (from nat-traversal-02.)

> 
> Draft defines three services and secure counterparts for them. This 
> could also be simplified by using already defined HIP parameters, 
> resulting in three simple services.
> 

This is nice, using HIP parameters instead of separate "applications" in
OpenDHT.

> Taking this to account I am suggesting a new "resolver" type packet
that 
> could be used with OpenDHT. Nothing prevents this to be used with 
> OpenLDAP or even with DNS. This packet could be like:
> 
> HIP header + LOCATOR + [HOST-ID] + [HIP_SIGNATURE]
> 
> HIP header in this would tell that this is HIP resolver (storage
format) 
> packet and it would have src HIT as the senders HIT. Dst HIT should be

> all zeroes, because there is no dst in particular.
> 
> LOCATOR would contain all addresses that the client is willing to 
> publish at this time.

To reiterate a previous comment, I consider the DHT lookup as an initial
bootstrapping for HIP when you are looking for an initial address to
send an I1. I think you would just want a single locator to kick off the
HIP exchange, and the full set of locators can be exchanged using HIP's
UPDATE mechanism at a later time.

However, as you (or someone) mentioned before, you may have both public
IPv4 and IPv6 locators on which you want to be reachable, so you'd need
to store both. Storing multiple LOCATORs does seem like the most
flexible option anyway.

> 
> Optional HOST-ID would be used to inform about DI and/or public HI. If

> only other is used the others length should be marked as  zero. DI
part 
> could be used to point to the DNS system. When client connects to HIT,

> its name could be found from the OpenDHT and then other information 
> resolved from DNS by using it. Public HI part is useful when working 
> with certs.

This is an interesting DHT and DNS interaction. As you mention, this
supplies a sort of HIT-to-name reverse lookup. 

> 
> HIP_SIGNATURE is useful, by signing the message we know that it is 
> intact and it comes from the HIT it claims. I marked it optional but I

> would prefer it as a mandatory field, because OpenDHT is open system
to 
> use by anyone. And this would at least improve the security a little
bit.
> 
> In this approach all the information could be sent in one message and 
> save some bandwidth. Because of the usage of already defined HIP 
> parameters, the implementation is easy. Handlers for the parameters 
> already exist. Also the secure versions of the services could be 
> removed, because of (mandatory) HIP_SIGNATURE. Or if optional it could

> be just mentioned that if present the message is secure.
> 
> This approach might benefit the NAT traversal guys also.
> 
> Hopefully I didn't forget anything.
> 
> Now its time for comments and discussion :)
> 

These changes Sound good to me. With the HIP_SIGNATURE being optional, a
HIP host accepting this resolver packet may receive it with a grain of
salt if the signature is missing. It could choose to only use signed
records per local policy.

-Jeff

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 13 Dec 2007 16:57:03 +0100
Subject: [Hipsec-rg] Proposing a new packet type for resolving purposes (draft-ahrenholz-hiprg-dht-01)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday 13 December 2007, Kristian Slavov wrote:
> Hi,
>
> Brief comment below.
>
> Samu Varjonen wrote:
> > Hi,
> >
> > I am proposing a change in the way addresses are handled in HIP DHT
> > interface draft.
> >
> > Currently the 01 suggests to use sockaddrs when storing addresses
> > to OpenDHT. And on multihoming cases this leads to case where every
> > IP is considered as a different value under one key. OpenDHTs
> > accepts only one put per connection and then it closes the
> > connection. This leads to multiple connection establishments, when
> > client has multiple addresses. While all addresses and some other
> > information could be sent in more convenient way. This has been
> > discussed on the list previously and then I suggested the usage of
> > LOCATOR parameter.
> >
> > Draft defines three services and secure counterparts for them. This
> > could also be simplified by using already defined HIP parameters,
> > resulting in three simple services.
> >
> > Taking this to account I am suggesting a new "resolver" type packet
> > that could be used with OpenDHT. Nothing prevents this to be used
> > with OpenLDAP or even with DNS. This packet could be like:
> >
> > HIP header + LOCATOR + [HOST-ID] + [HIP_SIGNATURE]
>
> Are you supposed to have an established HIP association with the
> directory server prior to sending this packet? If not, then how do
> you prevent replay attacks (of the proposed packet)?

Adding a timestamp under the signature would give reasonable protection 
against replay attacks.

--julien

From: krisu at nomadiclab.com (Kristian Slavov)
Date: Thu, 13 Dec 2007 17:03:41 +0200
Subject: [Hipsec-rg] Proposing a new packet type for resolving purposes (draft-ahrenholz-hiprg-dht-01)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Brief comment below.

Samu Varjonen wrote:
> Hi,
> 
> I am proposing a change in the way addresses are handled in HIP DHT 
> interface draft.
> 
> Currently the 01 suggests to use sockaddrs when storing addresses to 
> OpenDHT. And on multihoming cases this leads to case where every IP is 
> considered as a different value under one key. OpenDHTs accepts only one 
> put per connection and then it closes the connection. This leads to 
> multiple connection establishments, when client has multiple addresses. 
> While all addresses and some other information could be sent in more 
> convenient way. This has been discussed on the list previously and then 
> I suggested the usage of LOCATOR parameter.
> 
> Draft defines three services and secure counterparts for them. This 
> could also be simplified by using already defined HIP parameters, 
> resulting in three simple services.
> 
> Taking this to account I am suggesting a new "resolver" type packet that 
> could be used with OpenDHT. Nothing prevents this to be used with 
> OpenLDAP or even with DNS. This packet could be like:
> 
> HIP header + LOCATOR + [HOST-ID] + [HIP_SIGNATURE]

Are you supposed to have an established HIP association with the directory
server prior to sending this packet? If not, then how do you prevent replay
attacks (of the proposed packet)?

BR,
-- 
Krisu

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Thu, 13 Dec 2007 13:33:10 +0200
Subject: [Hipsec-rg] Proposing a new packet type for resolving purposes (draft-ahrenholz-hiprg-dht-01)
Message-ID: <[email-masked]>

Hi,

I am proposing a change in the way addresses are handled in HIP DHT 
interface draft.

Currently the 01 suggests to use sockaddrs when storing addresses to 
OpenDHT. And on multihoming cases this leads to case where every IP is 
considered as a different value under one key. OpenDHTs accepts only one 
put per connection and then it closes the connection. This leads to 
multiple connection establishments, when client has multiple addresses. 
While all addresses and some other information could be sent in more 
convenient way. This has been discussed on the list previously and then 
I suggested the usage of LOCATOR parameter.

Draft defines three services and secure counterparts for them. This 
could also be simplified by using already defined HIP parameters, 
resulting in three simple services.

Taking this to account I am suggesting a new "resolver" type packet that 
could be used with OpenDHT. Nothing prevents this to be used with 
OpenLDAP or even with DNS. This packet could be like:

HIP header + LOCATOR + [HOST-ID] + [HIP_SIGNATURE]

HIP header in this would tell that this is HIP resolver (storage format) 
packet and it would have src HIT as the senders HIT. Dst HIT should be 
all zeroes, because there is no dst in particular.

LOCATOR would contain all addresses that the client is willing to 
publish at this time.

Optional HOST-ID would be used to inform about DI and/or public HI. If 
only other is used the others length should be marked as zero. DI part 
could be used to point to the DNS system. When client connects to HIT, 
its name could be found from the OpenDHT and then other information 
resolved from DNS by using it. Public HI part is useful when working 
with certs.

HIP_SIGNATURE is useful, by signing the message we know that it is 
intact and it comes from the HIT it claims. I marked it optional but I 
would prefer it as a mandatory field, because OpenDHT is open system to 
use by anyone. And this would at least improve the security a little bit.

In this approach all the information could be sent in one message and 
save some bandwidth. Because of the usage of already defined HIP 
parameters, the implementation is easy. Handlers for the parameters 
already exist. Also the secure versions of the services could be 
removed, because of (mandatory) HIP_SIGNATURE. Or if optional it could 
be just mentioned that if present the message is secure.

This approach might benefit the NAT traversal guys also.

Hopefully I didn't forget anything.

Now its time for comments and discussion :)

BR,
Samu

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Tue, 11 Dec 2007 13:39:44 +0200
Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> From my (perhaps unnecessarily) strict HIP point of view, I find  
>> [P2PSIP WG] discussions quite silly.  They look at HIP as HIP was  
>> a set of nails and a hammer while HIP actually is a carefully  
>> constructed, ready made box that can be used to carry many  
>> different things.
>>
> To try to summarize the P2PSIP environment with respect to HIP, I  
> believe that the following has occurred.  P2PSIP has a set of  
> requirements or goals and several technical proposals in response.   
> There is an identified need for a distributed overlay for routing  
> and name resolution, interest in using distributed hash tables and  
> flat IDsfor this overlay, and NAT traversal requirements.  Several  
> people have looked at this and recognized that HIP admits a similar  
> architecture, and that if you squint at both of these from a  
> distance, they look similar.
>
> However, we in HIP are not ready to suggest to this community to  
> "just use the ready-made HIP box," because to work in this  
> scenario, there are aspects of HIP that have not yet been deployed  
> or standardized, so HIP *as presently specified by the WG RFCs*  
> can't yet deliver on all of the P2PSIP goals/requirements.

I agree with your characterisation.

> Hence, several views have emerged on how to use HIP or pieces of  
> HIP to solve the P2PSIP problem.

Right, but to me many aspects those approaches seem more-or-less  
uninformed.  HIP-HOP looks best informed of those, but then the  
authors (Hi Philip) claim to have encountered problems that I don't  
understand.  To me most -- if not all -- of those "problems" are  
merely misconceptions, or failure to understand how HIP is designed  
to be extensible.  (Yes, I know that we have never explicitly  
explained that.  That's why I've started to write a draft about  
that.)  I'm sorry to say this (and perhaps partially guilty myself),  
but I find the with-hip approach to contain many architecturally very  
ugly aspects.  OTOH, the authors have told me that they approach is  
more a political compromise than an attempt to create a clean  
architecture.  Sigh.

Anyway, returning to HIP overlays, I think we known quite a lot.

First, we have the Hi3 papers and the expired draft, which together  
already a few years ago outlined pretty well how one can produce a  
HIP-based overlay that not only has NATs but also firewalls.   
(Granted, the Hi3 work didn't directly address legacy NAT traversal,  
but I still maintain that it is a trivial problem and the DT has gone  
architecturally astray.  But I digress here -- need to continue that  
on the WG ML.)

Second, we have the Ambient Networks NodeID architecture that shows  
one specific way of how to solve the associated identity routing  
problems and how to add IP-addressing realms to such an  
architecture.  And there is even a working prototype of that  
architecture.

Hence, I would say that at the theoretical level we know pretty well  
how do build HIP-based overlays.  On the other hand, I admit that  
finding the relevant research results may be challenging to anyone  
who hasn't been following the research.  And none of that has been  
standardised, of course.

> And there is some urgency to respond if we would like HIP to be  
> considered as part of the solution for that WG.

That is a fine goal for spreading information about HIP, but I have  
to admit that I have personally lost faith to the P2PSIP WG.  Of what  
I've heard, to me it is pretty clear that they will never be able to  
produce a "Skype killer", which I've understood to be behind much of  
the energy.  OTOH, for enterprise solutions I don't really understand  
why they would need the kind of architecture they are planning.  But  
I digress, again.  Sorry for that.

> I agree with you that we should work towards a generic HIP-based  
> overlay, but my point is that it does not exist yet and we should  
> recognize that and try to remedy that.

I agree that such an overlay does not exist as specifications, but  
there are research papers and at least one prototype of such  
solutions, as I pointed out above.

> And we also need to consider deployment issues (and possibly  
> compromises as a result) because the generic pervasive HIP-based  
> overlay is not going to materialize on its own.  So the various  
> drafts make sense to me in that regard.

This is an important point.  I'll try to return to this on the NAT  
traversal issue, at the WG side, since I think the related concerns  
are even more visible there.

>> 1. HIP can considered as a small but significant step towards a  
>> "new" inter-networking layer.  That is, opposed to some people  
>> that want to  play down the layer-like characteristics of HIP, I  
>> think that HIP is  a step towards an architecture, perhaps  
>> something like Ambient Networks Node ID or Hi3, where HIP is used  
>> to establish end-to-end  connectivity over IPv4 and IPv6,  
>> including (architected) NATs.
>
> As someone who has wanted to play down that aspect, I can say that  
> I tend to think of and describe HIP as an additional namespace for  
> networking more than as a new layer.  When it is depicted as a  
> layer in architectural diagrams, it implies at first glance that  
> all TCP/IP communications pass through this new layer, which is not  
> really the case.

I think this is due to the common misconception that people have  
about the TCP/IP architecture.  While it is traditionally drawn as a  
stack, it is really more like a "staircase" where the layers above  
access to all of the layers below.

But I admit that there is a human-level communication problem here.   
The "layers" view does not make it clear that HIP is really today an  
optional layer, if a layer at all.  Only when we start to consider  
issues like v4/v6 interoperability, mobility, NAT traversal, etc. it  
becomes a (more) real layer.  That is, there you cannot communicate  
without it, unless you adopt other solutions for the functions the  
HIP "layer" provides.

> Certainly, it may evolve to become a new internetworking layer but  
> from a deployment perspective for today's applications, it is more  
> of an extension right now to the layers we have than a new layer.

Yep, I agree.

>  Perhaps my view is colored by incremental deployment considerations.

Deployment is a very valid point.  Perhaps my view is coloured by  
architectural purity. :-)

>> Most importantly, this means that we should avoid circular  
>> dependencies that make HIP _dependent_ on protocols that are  
>> architecturally above transport...
>
> I think the main dependencies being considered are deployment- 
> related.  HIP right now does not have its own relays, resolution  
> service, etc. so there have been proposals to reuse the P2PSIP- 
> defined one to do those things, or blend the two together.

Right.  There are two aspects here.

1. From my architectural purity point of view, I find such blendings  
exceedingly ugly.

2. I still believe that even for NAT-traversal we will need HIP RVS  
servers, thereby making the point moot.  But, again, that discussions  
belongs to the WG NAT-traversal side.

>> What do others think?  Does this make sense to you?  Or would it  
>> be better to use HIP in a more ad hoc (i.e., per purpose) manner,  
>> such as those outlined in the above mentioned P2PSIP drafts?
>
> I think that P2PSIP is potentially a very nice use case for the  
> type of HIP networks that we have envisioned, and moreover the  
> potential usage goes beyond the SIP application.  I also think that  
> HIP RG/WG needs to do more work to meet the needs of such networks.

I am fully behind such goals.  My main point is that I find most of  
the P2PSIP discussion that I've heard of (through second hand)  
somewhat clueless and/or uninformed, at least when it comes to what  
HIP is and how it should be applied.  Hence, I think the present  
discussion is very important, if for nothing else then for clearing  
things out.  That's why I am participating to this, even if I'm  
generally reluctant to any more participate to detail discussions  
about HIP.

I do know that I represent here one extreme opinion, that of  
architectural purity.  I really appreciate that other people, like  
you, care more about deployment and other more practical issues, as I  
personally find hard to make design compromises in that space.  OTOH,  
I can *live* with such compromises, once they are done -- I just  
cannot digest designing such ugly things myself.  :-)

> I also think that as these types of use cases emerge, HIP will need  
> to justify the benefits and account for the costs of the additional  
> indirection in the stack, and incremental deployment incentives are  
> very
> important to get right.

I agree.

> I believe that you are advocating that we work on solving this  
> general overlay design problem and I support that, but I'd also  
> like to see whether something interesting emerges from the attempt  
> to deploy HIP with P2PSIP.

I think your goals are fine and very admirable.  I just personally  
cannot care that much about P2PSIP, as I have little faith in them  
ever succeeding in the larger scale.   To me P2PSIP is just one pin  
at the HIP bowling alley.  Unfortunately, to me it looks like a pin  
that fails to fulfil the basic requirements for successful pins,  
i.e., it does not seem to solve a problem in a 10-fold better way, as  
pins should do.  [Ref: Geoffrey Moore's Chasm Model.]

--Pekka

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Tue, 11 Dec 2007 11:24:11 +0200
Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Spencer,

Maybe the term "connectivity overlay" was poorly chosen.  What I  
meant is that HIP could provide connectivity over IPv4 and IPv6 where  
there currently is no end-to-end connectivity, e.g., due to NATs or  
due to different routing realms.

With signalling and data taking different paths I meant that HIP  
packets may take a different path than end-to-end data packets, i.e.,  
those packets that are today carried using ESP but that may in the  
future also use different data protocols, such as SRTP.  That is, we  
may have an "overlay" routing infrastructure (e.g. based on a DHT)  
for HIP control packets while using traditional IP, with realm- 
gateways, for the data packets.  The main reason why we may need this  
is that it is hard to aggregate HITs, therefore possibly making it  
too costly to create an optimal routing infrastructure for them.   
Consequently, if HIT-based routing is costly (in terms of hops and/or  
latency), it makes sense to utilise more optimal routes for the  
actual end-to-end data.

Did I make myself any clearer?

--Pekka

On 11 Dec 2007, at 00:22, Spencer Dawkins wrote:

> Hi, Pekka,
>
> Thanks for your note (yes, P2PSIP needs to figure out its protocol  
> stack).
>
> I understood almost everything, but had a couple of questions.
>
> - I'm not sure what you meant by connectivity overlay - is this  
> merely that
> we need to establish connectivity for HIP as we establish  
> routability for
> IPv4/IPv6?
>
> - When you said "signaling and data may take different paths",  
> could you
> point me toward more information about this? I keep thinking of HIP  
> as the
> new IP, but I thought HIP packets did not carry a user payload (yet?).
>
> Thanks,
>
> Spencer
>
>
>> Folks,
>>
>> There has been some e-mail exchanges after the Vancouver meeting
>> about the reactions within the P2PSIP group towards the three
>> different HIP-related P2PSIP proposals,
>>   draft-matthews-p2psip-hip-hop
>>   draft-hautakorpi-p2psip-with-hip
>>   draft-matthews-p2psip-id-loc
>>
>> From my (perhaps unnecessarily) strict HIP point of view, I find
>> those discussions quite silly.  They look at HIP as HIP was a set of
>> nails and a hammer while HIP actually is a carefully constructed,
>> ready made box that can be used to carry many different things.
>>
>> In more practical terms, I think we should still work towards a
>> generic HIP-based connectivity overlay, as we discussed already a few
>> years ago at the RG workshop before the Washington IETF meeting in  
>> 2004.
>>
>> To reach such a goal, I think it would be beneficial to look at HIP
>> from the following architectural viewpoints:
>>
>> 1. HIP can considered as a small but significant step towards a "new"
>> inter-networking layer.  That is, opposed to some people that want to
>> play down the layer-like characteristics of HIP, I think that HIP is
>> a step towards an architecture, perhaps something like Ambient
>> Networks Node ID or Hi3, where HIP is used to establish end-to-end
>> connectivity over IPv4 and IPv6, including (architected) NATs.
>>
>> 2. HIP lies genuinely below the transport, i.e., below UDP, TCP,
>> SCTP, and DCCP.  From this point of view, HIP forms the new waist of
>> the stack.  The way UDP is used to pass HIP packets in a legacy
>> NATted environment is a temporary hack that will eventually go away.
>>
>> Most importantly, this means that we should avoid circular
>> dependencies that make HIP _dependent_ on protocols that are
>> architecturally above transport, such as SIP, various DHT proposals,
>> etc.  HIP should be self-sustaining, the same way IP is, without any
>> dependencies to the layers above.  OTOH, optimisations where HIP
>> optionally uses existing upper-layer infrastructure to speed up
>> things, like connection establishment, are fine.
>>
>> 3. There are no fundamental difference between NAT traversal,
>> mobility, multi-homing, or connectivity overlays.  These are all
>> various aspects of the new interconnectivity layer, to be formed.
>>
>> If you think about those three, you should see where I'm going.  In
>> my vision, HIP forms a kind-of a new IP layer, providing end-to-end
>> connectivity, with four major differences to the present one:
>>
>> a. You have to signal first (HIP base exchange)
>> b. You need to get authorised (implicitly by base exchange)
>> c. Signalling and data may take distinct paths
>> d. As a result of signalling, the network may create soft state
>>
>> Given that, there remains two problems:
>>
>> i) How to create HIT-based forwarding tables
>> ii) How to bootstrap a node
>>
>> Comparing to IP, the problem of creating forwarding tables is
>> analogous to the problem that the routing protocols (OSPF, BGP, ...)
>> solve for IP.  Hence, there we apparently want to architecture the
>> system so that there can be multiple options, configured by local
>> administrator.  From this point of view, the P2PSIP overlay (DHT)
>> would be one particular way of building HIP-layer forwarding tables.
>>
>> For IP, bootstrapping is taken care by local configuration or DHCP.
>> For HIP, we apparently want something similar, and indeed in the very
>> early HIP drafts there was support for local bootstrapping, but it
>> was later on removed.
>>
>> What do others think?  Does this make sense to you?  Or would it be
>> better to use HIP in a more ad hoc (i.e., per purpose) manner, such
>> as those outlined in the above mentioned P2PSIP drafts?
>>
>> --Pekka Nikander
>>
>> _______________________________________________
>> Hipsec-rg mailing list
>> Hipsec-rg at listserv.cybertrust.com
>> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>>
>
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 10 Dec 2007 15:28:12 -0800
Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka, thank you for initiating the discussion-- some responses below. 

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander at nomadiclab.com] 
> Sent: Monday, December 10, 2007 11:12 AM
> To: hipsec-rg at listserv.cybertrust.com
> Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
> 
> Folks,
> 
> There has been some e-mail exchanges after the Vancouver meeting  
> about the reactions within the P2PSIP group towards the three  
> different HIP-related P2PSIP proposals,
>    draft-matthews-p2psip-hip-hop
>    draft-hautakorpi-p2psip-with-hip
>    draft-matthews-p2psip-id-loc
> 
>  From my (perhaps unnecessarily) strict HIP point of view, I find  
> those discussions quite silly.  They look at HIP as HIP was a set of  
> nails and a hammer while HIP actually is a carefully constructed,  
> ready made box that can be used to carry many different things.
> 
> In more practical terms, I think we should still work towards a  
> generic HIP-based connectivity overlay, as we discussed 
> already a few  
> years ago at the RG workshop before the Washington IETF 
> meeting in 2004.

To try to summarize the P2PSIP environment with respect to HIP, I
believe that the following has occurred.  P2PSIP has a set of
requirements or goals and several technical proposals in response.
There is an identified need for a distributed overlay for routing and
name resolution, interest in using distributed hash tables and flat IDs
for this overlay, and NAT traversal requirements.  Several people have
looked at this and recognized that HIP admits a similar architecture,
and that if you squint at both of these from a distance, they look
similar.

However, we in HIP are not ready to suggest to this community to "just
use the ready-made HIP box," because to work in this scenario, there are
aspects of HIP that have not yet been deployed or standardized, so HIP
*as presently specified by the WG RFCs* can't yet deliver on all of the
P2PSIP goals/requirements.  Hence, several views have emerged on how to
use HIP or pieces of HIP to solve the P2PSIP problem.  And there is some
urgency to respond if we would like HIP to be considered as part of the
solution for that WG.

I agree with you that we should work towards a generic HIP-based
overlay, but my point is that it does not exist yet and we should
recognize that and try to remedy that.   And we also need to consider
deployment issues (and possibly compromises as a result) because the
generic pervasive HIP-based overlay is not going to materialize on its
own.  So the various drafts make sense to me in that regard.

> 
> To reach such a goal, I think it would be beneficial to look at HIP  
> from the following architectural viewpoints:
> 
> 1. HIP can considered as a small but significant step towards 
> a "new"  
> inter-networking layer.  That is, opposed to some people that 
> want to  
> play down the layer-like characteristics of HIP, I think that HIP is  
> a step towards an architecture, perhaps something like Ambient  
> Networks Node ID or Hi3, where HIP is used to establish end-to-end  
> connectivity over IPv4 and IPv6, including (architected) NATs.

As someone who has wanted to play down that aspect, I can say that I
tend to think of and describe HIP as an additional namespace for
networking more than as a new layer.  When it is depicted as a layer in
architectural diagrams, it implies at first glance that all TCP/IP
communications pass through this new layer, which is not really the
case.  Certainly, it may evolve to become a new internetworking layer
but from a deployment perspective for today's applications, it is more
of an extension right now to the layers we have than a new layer.
Perhaps my view is colored by incremental deployment considerations.

> 
> 2. HIP lies genuinely below the transport, i.e., below UDP, TCP,  
> SCTP, and DCCP.  From this point of view, HIP forms the new waist of  
> the stack.  The way UDP is used to pass HIP packets in a legacy  
> NATted environment is a temporary hack that will eventually go away.
> 
> Most importantly, this means that we should avoid circular  
> dependencies that make HIP _dependent_ on protocols that are  
> architecturally above transport, such as SIP, various DHT proposals,  
> etc.  HIP should be self-sustaining, the same way IP is, without any  
> dependencies to the layers above.  OTOH, optimisations where HIP  
> optionally uses existing upper-layer infrastructure to speed up  
> things, like connection establishment, are fine.

I think the main dependencies being considered are deployment-related.
HIP right now does not have its own relays, resolution service, etc. so
there have been proposals to reuse the P2PSIP-defined one to do those
things, or blend the two together.

> 
> 3. There are no fundamental difference between NAT traversal,  
> mobility, multi-homing, or connectivity overlays.  These are all  
> various aspects of the new interconnectivity layer, to be formed.
> 
> If you think about those three, you should see where I'm going.  In  
> my vision, HIP forms a kind-of a new IP layer, providing end-to-end  
> connectivity, with four major differences to the present one:
> 
> a. You have to signal first (HIP base exchange)
> b. You need to get authorised (implicitly by base exchange)
> c. Signalling and data may take distinct paths
> d. As a result of signalling, the network may create soft state
> 
> Given that, there remains two problems:
> 
> i) How to create HIT-based forwarding tables
> ii) How to bootstrap a node
> 
> Comparing to IP, the problem of creating forwarding tables is  
> analogous to the problem that the routing protocols (OSPF, BGP, ...)  
> solve for IP.  Hence, there we apparently want to architecture the  
> system so that there can be multiple options, configured by local  
> administrator.  From this point of view, the P2PSIP overlay (DHT)  
> would be one particular way of building HIP-layer forwarding tables.
> 
> For IP, bootstrapping is taken care by local configuration or DHCP.   
> For HIP, we apparently want something similar, and indeed in 
> the very  
> early HIP drafts there was support for local bootstrapping, but it  
> was later on removed.
> 
> What do others think?  Does this make sense to you?  Or would it be  
> better to use HIP in a more ad hoc (i.e., per purpose) manner, such  
> as those outlined in the above mentioned P2PSIP drafts?
> 

I think that P2PSIP is potentially a very nice use case for the type of
HIP networks that we have envisioned, and moreover the potential usage
goes beyond the SIP application.  I also think that HIP RG/WG needs to
do more work to meet the needs of such networks.  

I also think that as these types of use cases emerge, HIP will need to
justify the benefits and account for the costs of the additional
indirection in the stack, and incremental deployment incentives are very
important to get right. 

I believe that you are advocating that we work on solving this general
overlay design problem and I support that, but I'd also like to see
whether something interesting emerges from the attempt to deploy HIP
with P2PSIP.

Regards,
Tom

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 10 Dec 2007 16:22:55 -0600
Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Pekka,

Thanks for your note (yes, P2PSIP needs to figure out its protocol stack).

I understood almost everything, but had a couple of questions.

- I'm not sure what you meant by connectivity overlay - is this merely that 
we need to establish connectivity for HIP as we establish routability for 
IPv4/IPv6?

- When you said "signaling and data may take different paths", could you 
point me toward more information about this? I keep thinking of HIP as the 
new IP, but I thought HIP packets did not carry a user payload (yet?).

Thanks,

Spencer

> Folks,
>
> There has been some e-mail exchanges after the Vancouver meeting
> about the reactions within the P2PSIP group towards the three
> different HIP-related P2PSIP proposals,
>   draft-matthews-p2psip-hip-hop
>   draft-hautakorpi-p2psip-with-hip
>   draft-matthews-p2psip-id-loc
>
> From my (perhaps unnecessarily) strict HIP point of view, I find
> those discussions quite silly.  They look at HIP as HIP was a set of
> nails and a hammer while HIP actually is a carefully constructed,
> ready made box that can be used to carry many different things.
>
> In more practical terms, I think we should still work towards a
> generic HIP-based connectivity overlay, as we discussed already a few
> years ago at the RG workshop before the Washington IETF meeting in 2004.
>
> To reach such a goal, I think it would be beneficial to look at HIP
> from the following architectural viewpoints:
>
> 1. HIP can considered as a small but significant step towards a "new"
> inter-networking layer.  That is, opposed to some people that want to
> play down the layer-like characteristics of HIP, I think that HIP is
> a step towards an architecture, perhaps something like Ambient
> Networks Node ID or Hi3, where HIP is used to establish end-to-end
> connectivity over IPv4 and IPv6, including (architected) NATs.
>
> 2. HIP lies genuinely below the transport, i.e., below UDP, TCP,
> SCTP, and DCCP.  From this point of view, HIP forms the new waist of
> the stack.  The way UDP is used to pass HIP packets in a legacy
> NATted environment is a temporary hack that will eventually go away.
>
> Most importantly, this means that we should avoid circular
> dependencies that make HIP _dependent_ on protocols that are
> architecturally above transport, such as SIP, various DHT proposals,
> etc.  HIP should be self-sustaining, the same way IP is, without any
> dependencies to the layers above.  OTOH, optimisations where HIP
> optionally uses existing upper-layer infrastructure to speed up
> things, like connection establishment, are fine.
>
> 3. There are no fundamental difference between NAT traversal,
> mobility, multi-homing, or connectivity overlays.  These are all
> various aspects of the new interconnectivity layer, to be formed.
>
> If you think about those three, you should see where I'm going.  In
> my vision, HIP forms a kind-of a new IP layer, providing end-to-end
> connectivity, with four major differences to the present one:
>
> a. You have to signal first (HIP base exchange)
> b. You need to get authorised (implicitly by base exchange)
> c. Signalling and data may take distinct paths
> d. As a result of signalling, the network may create soft state
>
> Given that, there remains two problems:
>
> i) How to create HIT-based forwarding tables
> ii) How to bootstrap a node
>
> Comparing to IP, the problem of creating forwarding tables is
> analogous to the problem that the routing protocols (OSPF, BGP, ...)
> solve for IP.  Hence, there we apparently want to architecture the
> system so that there can be multiple options, configured by local
> administrator.  From this point of view, the P2PSIP overlay (DHT)
> would be one particular way of building HIP-layer forwarding tables.
>
> For IP, bootstrapping is taken care by local configuration or DHCP.
> For HIP, we apparently want something similar, and indeed in the very
> early HIP drafts there was support for local bootstrapping, but it
> was later on removed.
>
> What do others think?  Does this make sense to you?  Or would it be
> better to use HIP in a more ad hoc (i.e., per purpose) manner, such
> as those outlined in the above mentioned P2PSIP drafts?
>
> --Pekka Nikander
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
> 

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 10 Dec 2007 21:11:33 +0200
Subject: [Hipsec-rg] From P2PSIP over HIP to a generic HIP overlay
Message-ID: <[email-masked]>

Folks,

There has been some e-mail exchanges after the Vancouver meeting  
about the reactions within the P2PSIP group towards the three  
different HIP-related P2PSIP proposals,
   draft-matthews-p2psip-hip-hop
   draft-hautakorpi-p2psip-with-hip
   draft-matthews-p2psip-id-loc

 From my (perhaps unnecessarily) strict HIP point of view, I find  
those discussions quite silly.  They look at HIP as HIP was a set of  
nails and a hammer while HIP actually is a carefully constructed,  
ready made box that can be used to carry many different things.

In more practical terms, I think we should still work towards a  
generic HIP-based connectivity overlay, as we discussed already a few  
years ago at the RG workshop before the Washington IETF meeting in 2004.

To reach such a goal, I think it would be beneficial to look at HIP  
from the following architectural viewpoints:

1. HIP can considered as a small but significant step towards a "new"  
inter-networking layer.  That is, opposed to some people that want to  
play down the layer-like characteristics of HIP, I think that HIP is  
a step towards an architecture, perhaps something like Ambient  
Networks Node ID or Hi3, where HIP is used to establish end-to-end  
connectivity over IPv4 and IPv6, including (architected) NATs.

2. HIP lies genuinely below the transport, i.e., below UDP, TCP,  
SCTP, and DCCP.  From this point of view, HIP forms the new waist of  
the stack.  The way UDP is used to pass HIP packets in a legacy  
NATted environment is a temporary hack that will eventually go away.

Most importantly, this means that we should avoid circular  
dependencies that make HIP _dependent_ on protocols that are  
architecturally above transport, such as SIP, various DHT proposals,  
etc.  HIP should be self-sustaining, the same way IP is, without any  
dependencies to the layers above.  OTOH, optimisations where HIP  
optionally uses existing upper-layer infrastructure to speed up  
things, like connection establishment, are fine.

3. There are no fundamental difference between NAT traversal,  
mobility, multi-homing, or connectivity overlays.  These are all  
various aspects of the new interconnectivity layer, to be formed.

If you think about those three, you should see where I'm going.  In  
my vision, HIP forms a kind-of a new IP layer, providing end-to-end  
connectivity, with four major differences to the present one:

a. You have to signal first (HIP base exchange)
b. You need to get authorised (implicitly by base exchange)
c. Signalling and data may take distinct paths
d. As a result of signalling, the network may create soft state

Given that, there remains two problems:

i) How to create HIT-based forwarding tables
ii) How to bootstrap a node

Comparing to IP, the problem of creating forwarding tables is  
analogous to the problem that the routing protocols (OSPF, BGP, ...)  
solve for IP.  Hence, there we apparently want to architecture the  
system so that there can be multiple options, configured by local  
administrator.  From this point of view, the P2PSIP overlay (DHT)  
would be one particular way of building HIP-layer forwarding tables.

For IP, bootstrapping is taken care by local configuration or DHCP.   
For HIP, we apparently want something similar, and indeed in the very  
early HIP drafts there was support for local bootstrapping, but it  
was later on removed.

What do others think?  Does this make sense to you?  Or would it be  
better to use HIP in a more ad hoc (i.e., per purpose) manner, such  
as those outlined in the above mentioned P2PSIP drafts?

--Pekka Nikander

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 6 Dec 2007 15:36:43 -0800
Subject: [Hipsec-rg] Friday morning: HIP and P2PSIP discussion
Message-ID: <[email-masked]>

There will be an informal discussion of the approach of using HIP for  
P2PSIP on Friday morning 8:15 - 9:00 (during breakfast time). If you  
are interested, meet in the hall outside Salon #1, #2, #3 (on the  
second floor).

- Philip

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Thu, 6 Dec 2007 11:39:55 -0800
Subject: [Hipsec-rg] HIP implementation tests at IETF 70
Message-ID: <[email-masked]>

FYI, during this 70th IETF meeting, I performed some interop tests of the three HIP implementations. The results were favorable, with IPv4 and IPv6 base exchanges working between the OpenHIP implementation and InfraHIP and Ericsson test servers, and a wired to wireless mobility handoff with each was also successful.

Here is a summary...

InfraHIP:
- IPv4 openhip-0.5 to crossroads.infrahip.net base exchange OK; ESP traffic using ping6 <hit>, http://<hit> OK
- IPv6 openhip-0.5 to crossroads.infrahip.net base exchange OK; ESP traffic using ping6 <hit>, http://<hit> OK
- IPv4 readdress OK from wired to wireless, after updating OpenHIP code (see the CVS version)
- CLOSE/CLOSE ACK worked OK

Ericsson:
- IPv4 openhip-0.5 to woodstock4.hip4inter.net base exchange OK; ESP traffic using ping6 <hit> OK, http://<hit> failed (TCP SYNs sent but no responses)
- IPv6 openhip-0.5 to woodstock6.hip4inter.net base exchange OK; ESP traffic using ping6 <hit> OK, http://<hit> failed (TCP SYNs sent but no responses)
- IPv4 readdress OK from wired to wireless
- CLOSE/CLOSE ACK worked OK

-Jeff

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Tue, 04 Dec 2007 10:49:02 +0200
Subject: [Hipsec-rg] CFP: The 15th International Conference on Telecommunications, 16 - 19 June, 2008
Message-ID: <[email-masked]>

The 15th International Conference on Telecommunications,
has a paper submission deadline on January 14, 2007.
It has topics of interest to HIPRG and everybody is invited
to submit technical papers for review.

http://ict08.org/

Topics of interest include, but are not limited to:

    o IP Mobility and Multihoming
    o Mesh and Ad-hoc Networks
    o Sensor Networks o Broadcast and Satellite Communications
    o Routing and Addressing
    o Wireless Multimedia
    o Overlay Networks
    o Traffic Modeling
    o Peer-to-peer Technologies
    o Network Economics and Game Theoretic Modeling
    o Network Security
    o Network Management Applications
    o Quality of Service
    o Performance Evaluation
    o Resource Management and Congestion Control
    o Trust and Reputation
    o SPAM and SPIT Prevention
    o Cross-layer Interactions
    o Transport Protocols
    o IPv6 Deployment
    o Convergence of Broadcast and Communications Technologies
    o Solutions for Consumer Communications
    o Digital TV and Radio Broadcasting
    o IPTV and Mobile TV
    o Home Networks

About the conference:

ICT was first initiated by the Centre for Telecommunications Research,
King?s College London (UK) and is receiving the support of the Institute
of Electrical and Electronic Engineers (IEEE) and the Institution of
Engineering and Technology (IET, former IEE). Based on the initial
success of Dubai in 1994, ICT has been held annually in Bali (1995),
Istanbul (1996), Melbourne (1997), Chalkidiki, Greece (1998), Jeju,
Korea (1999), Acapulco, Mexico (2000), Beijing (2002), Tahiti (2003),
Fortaleza, Brazil (2004), Cape Town, South Africa (2005), Funchal,
Portugal (2006), and Penang, Malaysia (2007).

Many scientists, engineers, students, professionals and technical staff,
representing a variety of organizations such as universities, research
institutes, telecommunication operators and equipment manufacturers have
attended previous ICT events.

The 15th ICT will be held in St. Petersburg, Russia - the meeting point
of East and West. Through its stunning architecture and wonderful art
galleries and museums, among a number of other attractions, the wealth
of history of East and West can be seen and felt in this beautiful city.

Andrei