Subject: [P2PSIP] New draft: HIP BONE

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 21 Dec 2007 13:51:53 +0200

Hi,

we have seen a lot of discussions on how HIP could relate to P2PSIP on 
this list lately. While this level of interest on HIP is a good thing 
(from the HIP community's perspective), there have been a few 
misconceptions and misunderstandings on what is essential to HIP (e.g., 
the ID/locator split) and what are just design or configuration choices 
made in a given HIP deployment (e.g., using self-certifying identifiers).

With the draft below, we have tried to clarify a few of the design 
choices that can be made while defining the use of HIP in a given 
scenario (e.g., the use of a centralized enrollment server). In 
particular, we have focused on the use of HIP to build overlays. The 
draft also includes tutorial material on HIP so that readers who are not 
familiar with HIP can still follow what it is said in the draft.

http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt

The draft also discusses the relationship between HIP and P2PSIP. It 
clarifies that while HIP can be used to implement connection management, 
other functions such as overlay maintenance, and data storage and 
retrieval are implemented using a peer protocol such as RELOAD or P2PP. 
We thought that this clarification was important because it seems some 
people mistakingly thought HIP was a full-blown peer protocol proposal 
while, in reality, HIP only provides connection management.

Enjoy your Christmas reading! ;o)

Cheers,

Gonzalo

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 21 Dec 2007 11:23:50 -0500

Gonzalo,

Many thanks to you, Pekka, and Jani for putting in yet more effort to
try to clarify a possible role for HIP in P2PSIP.

At a high level, in section 5 you list two potential outcomes, which
are for the wg to settle on HIP for all connection management or for
the wg to not use hip, but retain modularity that allows it.  I would
rather see option 2 reworded along the lines of "the wg will develop a
protocol that uses HIP as one possible choice for its connection
management layer.  The HIP module will not be mandatory to implement,
but its specification will be developed by the wg."  I think that's
something along the lines of what you're thinking.  It's certainly
what I'm hoping the outcome will be.  I am sure there are other
options as well (ignore hip, try to maintain compatibility but don't
specify, etc).

On a specific issue, I'm still a little confused about where the line
is between what the overlay does with overlay routing and what
HIP-BONE should be responsible for.  Your section 3.2 proposes that I1
packets are sent across the Peer Protocol overlay.  Were I to
implement RELOAD on top of HIP-BONE, what exactly does this mean?
Does this mean that I send a RELOAD CONNECT message and the contents
of that message are now an I1 instead of ICE candidates?  Or would
RELOAD's CONNECT go away and RELOAD would simply try to send a message
directly to a new PeerID via its ORCHID and the HIP-BONE layer would
then produce an upcall to RELOAD asking that an I1 be tunneled across
the overlay?

Similarly, in section 3.3, you suggest that a HIP message could be
tunneled through the overlay rather than establishing a new connection
for a simple query.  Generally, dht maintenance operations and
resource query operations are somewhat distinct.  If I'm using
recursive routing, a resource query operation would never cause a new
connection to be formed, but instead the query would be routed across
the overlay by the Peer Protocol.  Assuming I'm understanding your
layering correctly, that would be implemented by the Peer Protocol
knowing the translation between the PeerID of the next hop that it has
a connection to and that peer's ORCHID (or LSI) and the Peer Protocol
would route the query message to that next hop just like it has a
direct IP connection (and generally be unaware of the difference).
So I'm unclear on when the mechanism in 3.3 would be invoked.  If I'm
using recursive routing, the only time I would send a message to a new
peer for which I do not have an existing connection would be:
- during dht maintenance if I decide I should have a connection with
this new peer
- if the application decides it wants to send an application-layer
message directly
RELOAD proposes to solve the first case using CONNECT messages, as
discussed above.  It also proposes to solve the second case with a
CONNECT message (or TUNNEL, as decided by the application).  This is I
think where HIP (or at least id/loc) has its biggest potential win.
Is the use of a new ORCHID by the application the proposed application
of section 3.3?  If so, how would the decision be made of when to
tunnel and when to open a new direct connection?

Bruce

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 21 Dec 2007 13:18:18 -0500 (EST)

My general concern with running a peer protocol (RELOAD or P2PP) on top of 
HIP is that one will need to understand somewhat two completely different 
documents (HIP and peer protocol document) to implement a working 
solution. That increases the bar for someone who will like to quickly 
design and develop a working p2p solution.

I think there is a need to carefully perform message overhead analysis of 
HIP under different levels of churn. I am a bit confused about splitting 
the functionality between the overlay layer and the HIP layer. Is peer 
protocol no more than an encoding mechanism when implemented on top of 
HIP?

-salman

On Fri, 21 Dec 2007, Gonzalo Camarillo wrote:

> Hi,
>
> we have seen a lot of discussions on how HIP could relate to P2PSIP on this 
> list lately. While this level of interest on HIP is a good thing (from the 
> HIP community's perspective), there have been a few misconceptions and 
> misunderstandings on what is essential to HIP (e.g., the ID/locator split) 
> and what are just design or configuration choices made in a given HIP 
> deployment (e.g., using self-certifying identifiers).
>
> With the draft below, we have tried to clarify a few of the design choices 
> that can be made while defining the use of HIP in a given scenario (e.g., the 
> use of a centralized enrollment server). In particular, we have focused on 
> the use of HIP to build overlays. The draft also includes tutorial material 
> on HIP so that readers who are not familiar with HIP can still follow what it 
> is said in the draft.
>
> other functions such as overlay maintenance, and data storage and retrieval 
> are implemented using a peer protocol such as RELOAD or P2PP. We thought that 
> this clarification was important because it seems some people mistakingly 
> thought HIP was a full-blown peer protocol proposal while, in reality, HIP 
> only provides connection management.
>

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 21 Dec 2007 22:16:18 +0200

Hi Bruce,

Let me try to clarify a few of your HIP-specific questions.  In  
general, we tried to clarify the proposed relationship between HIP  
and the peer protocols by the architectural analogy (in Section 6),  
where we state that HIP acts in a role similar to IP (forwarding that  
results in connectivity) and the peer protocols in a role similar to  
routing protocols such as OSPF, i.e., building the routing tables  
needed to do forwarding.

> packets are sent across the Peer Protocol overlay.

Well, not quite.  We propose that "Nodes in the overlay forward I1  
packets in a hop-by-hop fashion according to the overlay's routing  
table towards its destination."  While that is true, it is inaccurate  
in the sense that it does not make the distinction between the  
routing tables (as build by the peer protocols) and the forwarding  
tables (as used by HIP) clear enough.

A better way to state what we propose might be "Nodes participating  
into an overlay forward I1 packets in a hop-by-hop fashion over the  
HIP BONE using the  forwarding tables, which in turn are built based  
on the routing table constructed by the peer protocol for the  
overlay."  But that would be quite a bunch to engulf at one time.

> Were I to

[Caveat: I don't know RELOAD nor other peer protocols in detail.]

> then produce an upcall to RELOAD asking that an I1 be tunneled across

I cannot say anything about RELOAD's CONNECT, but my understanding is  
that a forwarding node would look at the next hop ORCHID based on the  
forwarding table, and then pass the packet to the HIP  
implementation.  The HIP implementation would then detect if there is  
an active HIP association towards that ORCHID.  If there is, the I1  
packet is passed over that HIP association.  If there are not but  
there is a valid locator associated with the next hop ORCHID, then  
the I1 packet is passed over IP using the locator.  If neither, there  
the forwarding table is faulty, and the HIP layer needs to kick the  
peer protocols to rebuild the forwarding table.  That is similar to  
the case where the IP layer kicks the routing layer whenever it drops  
a packet due to missing route.  An open question here is whether and  
how to report the error back, i.e., if there should be a function  
similar to ICMP.  If yes, HIP NOTIFY packets could be used for that  
purpose.

Further note that there are at least two choices of what to use as  
index to the forwarding table look up.  Either one can use the Peer  
ID, presumably carried in a new HIP parameter in the I1 packet, or  
one can use the ORCHID, carried in the source HIT field in the I1  
packet.   From the high level point of view, both would work equally  
well, but as usual the devil may lie in the details.  The latter  
would be structurally similar to the currently specified HIP  
rendezvous service, and has been used in previous suggestions for HIP- 
based overlays.

> for a simple query.

My perhaps faulty understanding is that such "tunnelling" would be  
structurally similar to the case in 3.2.  The only difference would  
be than in 3.2 we discussed forwarding I1 packets (and presumably the  
rest of the packets in the HIP base exchange), while in 3.3 we  
basically state that any HIP packets could be forwarded over the HIP  
BONE, similar to the I1s, without creating any new HIP association.   
In general, the proposed forwarding function is pretty similar to the  
IP overlay forward in Berkeley i3.

> So I'm unclear on when the mechanism in 3.3 would be invoked.

One situation where it would be needed is when the peers lose  
connectivity, e.g., due to both moving at the same time and no more  
knowing each other's locators.  In HIP as defined today, the peers  
would use a HIP rendezvous server to pass HIP mobility update packets  
to pass the new locators.  In the HIP BONE case, the idea is that the  
HIP rendezvous functionality is replaced by the HIP BONE, i.e., the  
overlay would be used to pass the mobility update packets.

Other than that I cannot answer your question about 3.3., since I  
didn't understand that much about it.  I am sorry, but I am really  
new to what is going on at P2PSIP.

I hope that my answers above clarify our thinking.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 21 Dec 2007 22:17:39 +0200

> I am a bit confused about splitting the functionality between the  
> overlay layer and the HIP layer. Is peer protocol no more than an  
> encoding mechanism when implemented on top of HIP?

At least to me it helped to try to understand the relationship as  
similar to the relationship between IP and routing protocols such as  
OSPF.  Please see Section 6 of the draft, and my previous message to  
this list.

--Pekka Nikander

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 21 Dec 2007 14:14:53 -0800

(I have changed the Subject name)

> I am sorry, but I am really  

Welcome to the crowd! 
Many of us are just as new to what is going on in HIP.

At this point time it seems we must bridge some interdisciplinary
divides alluded to in these postings.

Someone or a group that understands all three: HIP, DHT and SIP would be
very helpful with some message flows (call flows in SIP parlance). 

Using the example message flows, the debated points on the merits of HIP
and also possible duplication with TLS, DTL and SRTP could be
illustrated. Pushing the envelope; the associated protocol layer
diagrams would also help.

Diagrams and message flows are worth 1,000s of email words :-)

I am embarrassed to admit not knowing enough to volunteer to contribute.

Henry

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]] 
Sent: Friday, December 21, 2007 12:16 PM
To: Bruce Lowekamp
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: HIP BONE

Hi Bruce,

--Pekka Nikander

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 23 Dec 2007 11:33:48 +0200

Hi Bruce,

thanks for your comments.

Regarding your question about Sections 3.2 and 3.3 when RELOAD is the 
peer protocol and HIP BONE is used for connection management, the idea 
is to use HIP, instead of RELOAD, to perform connection management. All 
the other functions RELOAD typically performs are still performed by RELOAD.

RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is 
being used, you would use the CONNECT primitive of HIP (i.e., an I1 
packet) *instead* of the CONNECT primitive of RELOAD. The same way, you 
would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of 
the TUNNEL primitive of RELOAD.

Regarding when to use these primitives, you would use them in the same 
way as defined by RELOAD. That is, when RELOADs tells you to use a 
CONNECT primitive today, you would send an I1 message. When RELOAD tells 
you to use the TUNNEL primitive today, you would use a HIP message as 
well. That is, RELOAD (not HIP BONE) tells you what to do  (i.e., which 
primitive to use) and when to do it.

As you can see, the only modifications to RELOAD in this context is the 
substitution of these two primitives by the HIP equivalent ones.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 23 Dec 2007 11:46:20 +0200

Hi Salman,

> My general concern with running a peer protocol (RELOAD or P2PP) on top 
> of HIP is that one will need to understand somewhat two completely 
> different documents (HIP and peer protocol document) to implement a 
> working solution. That increases the bar for someone who will like to 
> quickly design and develop a working p2p solution.

that is because you get things like mobility and multihoming. If you 
want to implement these features without using HIP you will need to 
anyway read more specifications (e.g., mobile IP and SHIM-6).

> I think there is a need to carefully perform message overhead analysis 
> of HIP under different levels of churn.

The only difference is that, every time you a node establishes a 
connection with another node, there will be a HIP four-way handshake 
instead of a TLS or DTLS handshake.

> I am a bit confused about 
> splitting the functionality between the overlay layer and the HIP layer. 
> Is peer protocol no more than an encoding mechanism when implemented on 
> top of HIP?

No, the peer protocol provides all the functions it provides today 
except for the CONNECT and TUNNEL primitives (and NAT traversal).

If you mean that the peer protocol runs inside secure connections 
managed by HIP, that is also the case today: the peer protocol runs 
inside secure connections managed by TLS.

Cheers,

Gonzalo

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 24 Dec 2007 17:20:05 -0800

I wonder if similar simple substitutions don't work for most of the
other proposed P2PSIP protocols, in some common architectural approach.

Henry

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Sunday, December 23, 2007 1:34 AM
To: Bruce Lowekamp
Cc: Pekka Nikander; P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: HIP BONE

Hi Bruce,

Regarding your question about Sections 3.2 and 3.3 when RELOAD is the 
peer protocol and HIP BONE is used for connection management, the idea 
is to use HIP, instead of RELOAD, to perform connection management. All 
the other functions RELOAD typically performs are still performed by
RELOAD.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Dec 2007 14:28:24 +0200

Hi Henry,

yes, HIP BONE can be used with any peer protocol. I used RELOAD in my 
email below as one example of a peer protocol to make the explanation 
easier to understand.

Cheers,

Gonzalo

---

From: Ali Fessi <[email-masked]>
Date: Wed, 26 Dec 2007 13:53:38 +0100

Hi Gonzalo,

what is if peers add the HIP ORCHID at the first position of the list of 
gathered addresses for ICE?

Since a HIP overlay, let's say a HIP BONE, will provide e2e 
connectivity, peers in the same HIP BONE will then be able to 
communicate as if they would be in the same private network if they use 
the HIP ORCHID as "IP addresses" and they woule be able to benefit from 
all the advantages of using HIP.

If they are not in the same HIP BONE, they would need to establish 
connectivity through other type of addresses, e.g. those retreived by STUN.

Do you think that would work?

Cheers,
  Ali

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Dec 2007 15:14:00 +0200

Hi,

> gathered addresses for ICE?

ORCHIDs are identifiers. You need locators (i.e., IP addresses) for the 
ICE process.

Cheers,

Gonzalo

---

From: Ali Fessi <[email-masked]>
Date: Wed, 26 Dec 2007 14:14:28 +0100

Hi all,

just another hint for the HIP discussion:

if a HIP P2P overlay is used for P2PSIP, you will need 2 lookups in the 
overlay for establishing a SIP session:

- one for resolving the SIP URI to a HIP Identifier (HIT/ORCHID)
- and one for resolving the HIP Identifier to the current Locator (i.e. 
IP address)

Cheers,
  Ali

Gonzalo Camarillo wrote:
>> From: Gonzalo Camarillo [mailto:[email-masked]] Sent: 
>> Sunday, December 23, 2007 1:34 AM
>> To: Bruce Lowekamp
>> is to use HIP, instead of RELOAD, to perform connection management. 
>> All the other functions RELOAD typically performs are still performed by
>> RELOAD.
>>
>> packet) *instead* of the CONNECT primitive of RELOAD. The same way, 
>> you would use the TUNNEL primitive of HIP (i.e., a HIP message) 
>> *instead* of
>>
>> well. That is, RELOAD (not HIP BONE) tells you what to do  (i.e., 
>> which primitive to use) and when to do it.
>>
>> As you can see, the only modifications to RELOAD in this context is 
>> the substitution of these two primitives by the HIP equivalent ones.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Bruce Lowekamp wrote:
>>> Gonzalo,
>>>

---

From: Ali Fessi <[email-masked]>
Date: Wed, 26 Dec 2007 15:44:49 +0100

Dear Gonzalo, all,

according to draft-ietf-mmusic-ice, addresses collected for ICE can be 
also "obtained through a tunnel mechanism, such as a Virtual Private 
Network (VPN) or Mobile IP (MIP)".

If i understand correctly (please correct me if i am wrong) the ORCHID 
(alternatively the LSI if the application uses IPv4) is bound locally to 
a virtual interface. So the application can use it the same way it uses 
an IP address obtained by a VPN (or any other IP address, e.g. obtained 
by STUN)

So is there a reason why HIP ORCHIDs cannot be used in the ICE 
candidates list?

Also the ICE host candidates' sorting process (as described in Section 
2.3 "Sorting Candidates" in draft-ietf-mmusic-ice) could recognize the 
HIP ORCHID (due to the unique prefix) and give it higher priority in the 
host candidate list if the application should benefit from the HIP 
advantages.

I think that could provide a simple - though modular and flexible - 
approach for integrating HIP for P2PSIP (at least for the NAT traversal 
part)

In other words:

- the application can easily check whether the host where it is running 
supports HIP.

- a peer can inform another peer that it supports HIP (using the ICE 
candidates list and the priorities given to the addresses). If both 
peers support HIP and they are in the same HIP overlay, then they can 
(and maybe should) use it.

- if one of the peer hosts does not support HIP, then the peers will 
need to go forward in the ICE host candidate list and use other 
addresses for connectivity, e.g. those obtained by STUN.

I mentioned, this could provide a modular approach for the NAT traversal 
problem. But maybe it could be extended to cope with the other features 
that HIP provides, e.g. mobility and multi-homing.

Any comments?

Thanks in advance.

Cheers,
  Ali

Gonzalo Camarillo wrote:
> Hi,
> 
>> what is if peers add the HIP ORCHID at the first position of the list 
>> of gathered addresses for ICE?
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 26 Dec 2007 13:59:03 -0800

> rendezvous service, and has been used in previous suggestions 

Pekka,

If I understand correctly, you are suggesting that there would be HIP
forwarding table(s) with next hop ORCHIDs.  There may be next hop IP
addresses or active HIP tunnels corresponding to each next hop ORCHID.
There may be multiple peer protocols populating this HIP table.  

Then, it seems to be the case that there must be multiple HIP forwarding
tables, one for each overlay.  I think it has to be so because, unlike
routing, where different routing protocols will likely inject forwarding
table entries (prefixes) corresponding to separate regions of the IP
address space, each HIP-based overlay (and ORCHID space) overlaps the
ORCHID range completely.  Furthermore, nodes in a DHT will be
responsible for portions of the space and these portions will overlap
from overlay to overlay.

If so, then there is a requirement to be able to look up the right
forwarding table from an I1, which I think you are suggesting above in
the last paragraph.  So the I1 (and probably all HIP packets) needs to
carry some metadata about the ORCHID type in use, either in a new
parameter or embedded in a certificate.  Basically, there needs to be a
new namespace in use at the HIP forwarding layer-- the namespace
uniquely identifying overlays.  This could perhaps be the ORCHID Context
ID.  

Another related question I have is whether you think the legacy
application API (based on sockets) would work anymore with ORCHIDs,
because if you get a raw ORCHID across the sockets API, you can't tell
by inspecting the ORCHID which overlay it belongs to, because the
context ID is not visible.  It seems that you would need to pass
metadata about the ORCHID across the sockets API, so that the node knows
which ORCHID-based overlay that it belongs to, or else you need to use
LSIs even in the IPv6 case (as suggested by Philip Matthews at the
Vancouver meeting).

Tom

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 27 Dec 2007 15:31:06 +0200

>> In general, we tried to clarify the proposed relationship between  
>> HIP and the peer protocols by the architectural analogy [...],  
>> where we state that HIP acts in a role similar to IP [...] and the  
>> peer protocols in a role similar to routing protocols [...].

<snip>

>> A better way to state what we propose might be "Nodes  
>> participating into an overlay forward I1 packets in a hop-by-hop  
>> fashion over the HIP BONE using the  forwarding tables, which in  
>> turn are built based on the routing table constructed by the peer  
>> protocol for the  overlay."

<snip>

>> [...] my understanding is that a forwarding node would look at the  
>> next hop ORCHID based on the forwarding table, and then pass the  
>> packet to the HIP implementation.  The HIP implementation would  
>> then detect if there is an active HIP association towards that  
>> ORCHID.  If there is, the I1 packet is passed over that HIP  
>> association.  If there are not but there is a valid locator  
>> associated with the next hop ORCHID, then the I1 packet is passed  
>> over IP using the locator.

<snip>

>> index to the forwarding table look up:
>> 1) one can use the Peer ID, presumably carried in a new HIP  
>> parameter in the I1 packet, or
>> 2) one can use the ORCHID, carried in the source HIT field in the  
>> I1 packet.

<snip>

> If I understand correctly, you are suggesting that there would be  
> HIP forwarding table(s) with next hop ORCHIDs.  There may be next  
> hop IP addresses or active HIP tunnels corresponding to each next  
> hop ORCHID.

Yes, thought I'd prefer to say "next hop locators" instead of "next  
hop IP addresses", since I could imagine such locators also to have  
other forms, such as UDP tunnels for HIP signalling traffic or such.

> There may be multiple peer protocols populating this HIP table.

I didn't really think about that.  Hence, here we go forward from my  
previous thinking.

> Then, it seems to be the case that there must be multiple HIP  
> forwarding tables, one for each overlay.  [...]  Furthermore, nodes  
> in a DHT will be responsible for portions of the space and these  
> portions will overlap from overlay to overlay.

Yes, you are right.  Furthermore, the set of nodes in each overlay  
may be partially disjoint.

> forwarding table from an I1, which I think you are suggesting above  
> in the last paragraph.

Well, as far as I can see, that depends on the assumptions on the  
number of partially overlapping overlays.  If that number is small,  
the I could imagine that instead of picking just one forwarding table  
to use, one could simply replicate the I1 to all overlays in the case  
the right overlay is not know.  However, if replicating an I1, it  
would most probably make sense to tag it with the names of all  
overlays to which it is being sent to, or at least denote the primary  
overlay it was sent to.  But the details depend on detail  
requirements that I don't understand, e.g., what is the exact  
semantics of having multiple overlays.

> So the I1 (and probably all HIP packets) needs to carry some  
> metadata about the ORCHID type in use, either in a new parameter or  
> embedded in a certificate.

Right; that makes sense once a HIP signalling packet is being  
forwarded within an overlay.  I think a new parameter makes more  
sense, as it would most probably be more efficient to handle that.   
For other reasons, I was thinking of a parameter that would carry an  
ORCHID Context ID.

> Basically, there needs to be a new namespace in use at the HIP  
> forwarding layer -- the namespace
> uniquely identifying overlays.  This could perhaps be the ORCHID  
> Context ID.

I concur.

> because if you get a raw ORCHID across the sockets API, you can't  
> tell by inspecting the ORCHID which overlay it belongs to, because  
> the context ID is not visible.

Hmm.  The situation may be worse.  The case may well be that the app  
has no information at all about the overlays, so that it may not even  
be possible to tell the right overlay at all.  In such a case my  
suggestion above, i.e., to send the packet to all overlays  
simultaneously, might make sense.

> It seems that you would need to pass metadata about the ORCHID  
> across the sockets API, so that the node knows
> which ORCHID-based overlay that it belongs to, or else you need to  
> use LSIs even in the IPv6 case (as suggested by Philip Matthews at  
> the Vancouver meeting).

As far as I can see, that depends on the requirements.  If the  
requirement is simply create a secured connection to the peer if  
reachable at all, then IMHO it would make sense to try all of the  
overlays at the same time.  As long as the number of overlays is  
relatively small, the amount of additional traffic will be quite  
small, and originate from the source, i.e., is not replicated in the  
network.

--Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 27 Dec 2007 23:08:41 -0800

> From: Ali Fessi [mailto:[email-masked]] 
> Sent: Wednesday, December 26, 2007 6:45 AM
> To: Gonzalo Camarillo
> Cc: P2PSIP Mailing List
> Subject: [P2PSIP] a modular approach for integrating HIP for P2PSIP
> 
> Dear Gonzalo, all,
> 

If you cannot count on HIP being present below your application, you are
probably going to provide the functionality yourself (ICE, mobility
support, security) if you want to deploy a successful P2P application.
And if so, do you then care much about using HIP if/when it later enters
the picture?  (see also: IPv6 deployment...)

I think the interesting thing for P2PSIP to decide is whether to try to
go for an architecture where ICE/mobility handling is (non-optionally)
layered below the application so that such components can be reused
generally across applications.  Specifying it as an option will just
lead to it being replicated everywhere.  

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 27 Dec 2007 23:10:35 -0800

> Sent: Thursday, December 27, 2007 5:31 AM
> To: Henderson, Thomas R
> Cc: Bruce Lowekamp; P2PSIP Mailing List

<snip>

> small, and originate from the source, i.e., is not replicated in the  

There may be policy reasons for preferring the use of one overlay over
another, though.  And, IMO, it seems an inelegant solution akin to
replicating IP packets across all interfaces if one does not have a
route to the destination.

I think we need to be careful not to again conflate identifiers and
locators in the architecture, this time with ORCHIDs. 

Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Dec 2007 12:46:34 +0200

Hi Ali,

HIP includes an ICE-based NAT traversal mechanism. If two nodes use HIP, 
they will perform ICE at the HIP level, not at the application level. 
Using application-level ICE to negotiate the use of HIP between nodes, 
per your email below, is cumbersome. The use of HIP can be negotiated in 
simpler ways.

With regards to the use of HIP in overlays, the simplest way would be to 
  deploy overlays where all nodes use HIP and overlays where none of the 
nodes use HIP. However, some people have expressed interest in having 
mixed overlays where some nodes use HIP while others don't. If people 
are interested in doing this, we will have to look into ways to 
negotiate its use within the overlay.

Cheers,

Gonzalo

Ali Fessi wrote:
>> ORCHIDs are identifiers. You need locators (i.e., IP addresses) for 
>> the ICE process.
>>
>> Cheers,
>>
>> Gonzalo
>>
> 
>