Subject: Re: [P2PSIP] New version of draft-bryan-p2psip-reload

From: JiangXingFeng <[email-masked]>
Date: Thu, 19 Jun 2008 11:43:14 +0800

Hi, 
See inline.
Regards
JiangXingFeng
> Good point - I'm not really sure what to do here. I can see the use
> case you are making for connects to an ID that is different than the
> id of the node that ends up connecting. The only way I see to allow
> that is to remove the check but I'd have to think about if this breaks
> anything.

It would be better if the connect message is not designed specially for work
with ICE. So that other information than what ICE needed could also be
exchanged between two end nodes;

> Yes, I agree some sort of keep alive is needed to detect liveness on
> these connection. We also need to be able to deal with receiving a TCP
> RST for the TLS connections.

IMHO, a new keepalvie message is needed and could detect the connection
failure in time. A keepalive mechanism between two peers could also be used
to distribute some information like peers' capability or their changes so
that other peers could know the changes in time.
> >
> >
> > 4. In section 3.3.1, some routing alternatives are listed. As for
> > direct
> > response and relay peer, I think they could be well used together
> > with the
> > symmetric routing proposed in RELOAD-04 although there are some
> > limits with
> > their use. For example, the original peer could convey its contact
> > address
> > and/or the chosen relay peer information to the destination in the
> > request,
> > it's
> > up to the destination peer to choose whether send the response in
> > all ways
> > or
> > only in a subset of ways. In this way, they could bring enhancement
> > to the
> > symmetric routing.
> >
> > As for routing in the overlay, my major concern is still the
> > stablity of the
> >
> > reverse connection due to the churn. In my mind, symmetric routing
> > works
> > better
> > where the hops for the request is not big and direct response and
> > relay peer
> >
> > could provide much help when the hops is big. I've done a few work on
> > comparing
> > different routing modes listed in RELOAD-4 which has not finished
> > yet. If
> > some
> > data comes out, I will share them with the community.
> 
> I suspect this is an important topic worth of it's own thread. I look
> forward to seeing your work and I hope this is the sort of thing we
> end up getting time in the WG meetings to talk about because it is
> important. My main concern with all these is that the routing works
> well enough that two partitioned networks that each have a ring  can
> successfully merge back together.  Any scheme where that does not
> allow this would seem somewhat broken to me.
> 
As for partition, what I see the peer could do after he knows that is to
restart a join-like operation. The direct response and relay peer work in
the partition situation in the same way as in other situations. Am I missing
something?

What I suggest is to integrate symmetric routing mode, direct response,
relay peer into an integral routing mechanism and could work more efficient
than using a single  candidate mechanism. 
> 
> Well, I'm going to blame some other author on the 2^32 :-) but
> seriously this is allowed to be much larger than the IP MTU. The
> transport will need to deal with fragmenting and sending this. Clearly
> TCP already does this and in the case of UDP, reload provides
> fragmentation. There is not too much on that yet as it's fairly well
> understood how to do it and we just need to go add text and work with
> the transport folks on getting it right.

Basically, I don't like the fragmentation/reassembly idea. Because I think
it will introduce some security threats. For instance, a malicious peer may
send most of the fragments and does not send the rest on purpose, so that
the reassembly will not succeed in the destination peer. Then DoS attack
happens and will make the overlay unstable. 

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Jun 2008 07:50:48 -0700

At Thu, 19 Jun 2008 11:43:14 +0800,
> that other peers could know the changes in time.

We already have a keepalive message: UPDATE.

> happens and will make the overlay unstable. 

This is a consequence of having operations involving amounts of
data larger than can fit in a single MTU. It doesn't matter
where in the protocol that sort of reassembly happens. For
instance, you can do it at the TCP or TLS layer instead.
Moreover, I don't think this is much of a security threat.
There are well-known techniques for avoiding excessive
resource consumption from fragment reassembly.

-Ekr

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 19 Jun 2008 10:53:47 -0500

I have changed the title of the topic.

> exchanged between two end nodes;

This is just one instance that illustrates how/why HIP can contribute to a
better P2P SIP with NAT traversal, mobility, etc. There have been previous
posts to this effect, but the attached would make a great example in a usage
scenario of using HIP for P2PSIP.

Yes, I know, developing HIP code looks like opening a whole new can of
worms, but nothing compares to what we are looking at now when trying to
traverse NAT, support mobility, multihoming, etc. for each application
protocol and their various flavors separately.

I have copied some HIP folks  :-) to help me out in case people have doubts
about this axiom.

Henry

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 19 Jun 2008 15:10:23 -0400

> I have copied some HIP folks  :-) to help me out in case people have doubts

I think that the key discussions concerning HIP have focused not on 
whether it would be useful to applications, but on the exact layering 
required to make it work.  All proposals (with and without HIP) have ICE 
at the bottom layer, but how the applications use it and whether HIP is 
used for the peer protocol connections have varied.

Taking Section 3.2 of hip-bone-01 as an example, that proposal routes 
the I1 and I2 messages across the overlay (taking the place of the HIP 
rendezvous server).  reload-04 suggests accomplishing this by defining a 
HIP Tunnel Usage (in another draft). I'm very interested in the hip-bone 
authors' opinion of whether this technique meets their requirements for 
routing these messages.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 19 Jun 2008 15:24:37 -0400

> the partition situation in the same way as in other situations. Am I missing

You're right in that they work just as well as they do any other 
time---when they work they work fine, but if they don't work (due to NAT 
filtering, etc), you still need the fallback to symmetric routing.

> than using a single  candidate mechanism. 

The decision the WG will have to make is whether the complexity of 
additional routing mechanisms is worth the increased performance 
(removing a few hops on the return path).  We tried to apply Occam's 
Razor rather aggressively in evaluating features, and adding additional 
complexity to the protocol for these features seemed a bit questionable, 
at least for right now.

Now if you work in a world where NATs and firewalls don't exist, the 
world would be different, of course.

Bruce

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Jun 2008 09:42:26 +0300

Hi Henry,

> protocol and their various flavors separately.

yes, that is what HIP is about (i.e., implementing those functions at a 
lower layer so that they do not have to be redesigned by every single 
application-layer protocol).

Cheers,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Jun 2008 12:26:25 -0500

On Jun 26, 2008, at 1:42 AM, Gonzalo Camarillo wrote:

> yes, that is what HIP is about (i.e., implementing those functions  
> at a lower layer so that they do not have to be redesigned by every  
> single application-layer protocol).
>

This asks the question "Why don't we believe in HIP in this role?"

Is it because we've seen HIP struggling to advance for many years and  
think we can move more quickly?

Is it because we think the IETF's immune system will suppress HIP but  
that application-level work can move through?

Is it because we think that doing this stuff at the HIP level requires  
widespread OS and IP stack changes, but that we can deploy application- 
level solutions without it?

Is it because we think that if HIP solves the problems, then there  
will be no fun work left to do on applications?

Or is there something else?

There must be some reason, as I would think that if people really  
believed in HIP that the entire resources of the IETF would be bent  
towards getting it wrapped up and ready to go, since solving these  
problems again and again for every different application makes no more  
sense than would reinventing IP for every application.

--
Dean

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 26 Jun 2008 13:40:39 -0400

To some extent, these questions are orthogonal to the questions about a 
potential relationship between HIP and P2PSIP.

Using HIP in a decentralized manner requires a distributed rendezvous 
service (and distributed name service).  An overlay such as have been 
proposed by the various peer protocol proposals is ideal for running 
such services.

P2PSIP requires a distributed registrar service.  This service also 
requires a peer protocol (and some layers on top) and is not supplied by 
HIP.

Now there are still some architectural questions of whether the peer 
protocol connections should be formed using HIP or not and also 
questions about how to provide the best interface for applications using 
the services.

Regardless of the answers to those questions, I hope we can develop a 
peer protocol that can be extended to support the various models for 
interacting with HIP (and work without HIP) and let future development 
and deployments determine what architectures are truly useful.

Bruce

Dean Willis wrote:
>> yes, that is what HIP is about (i.e., implementing those functions at 
>> a lower layer so that they do not have to be redesigned by every 
> widespread OS and IP stack changes, but that we can deploy 
> application-level solutions without it?
> 
> Is it because we think that if HIP solves the problems, then there will 
> be no fun work left to do on applications?
>

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Thu, 26 Jun 2008 14:54:30 -0400

Hi, all:

It is a good technical debate.

There seems to be two kinds of trends as follows:

1. Take abstraction of lower layers to the upper as much one can for solving higher application layer problems (because lower layers are unable to provide satisfactory services to meet their those needs).

2. Make the applications independent of lower layers as much as you can (as billions of applications cannot afford in keeping up with the changes in the lower layers all the time - draining of resources - distractions from the main focus of building quality applications).

For item 1, cross-layer approaches are becoming popular in ad hoc mobile wireless environments. However, they seem to be stopped up to layer 3.

For item 2, it has been the trends from beginning of the computer communications networks. However, some of the problems faced in the lowers are not good enough to satisfy the upper layer applications' needs. For example, NAT crossing and ensuring of the end-to-end security for the real-time VoIP traffic.

What do we do?

We have to find a trade-off between the above two approaches. Let us see how we proceed in P2P-SIP protocol developments.

BR/Radhika

----- Original Message -----
From: Bruce Lowekamp 
Date: Thursday, June 26, 2008 13:48
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Dean Willis 
Cc: [email-masked], [email-masked], P2PSIP WG , [email-masked], Henry Sinnreich 

> >>> traverse NAT, support mobility, multihoming, etc. for each 
> application>>> protocol and their various flavors separately.
> >>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 26 Jun 2008 10:35:32 -0700

Dean,

Yes to all your questions.

Henry

On 6/26/08 10:26 AM, "Dean Willis" <[email-masked]> wrote:

>>> application

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Jun 2008 09:41:44 +0300

Hi Dean,

for sure you know about the Not Invented Here syndrome IETF WGs usually 
develop, right? ;o)

Cheers,

Gonzalo

---

From: David Barrett <[email-masked]>
Date: Fri, 27 Jun 2008 00:05:08 -0700

For what it's worth, I think P2PSIP over HIP is a fantastic idea, with 
the caveat that HIP should be deployable within standalone applications 
by statically linking some BSD-licensed library (ie, without requiring 
users to make TCP stack changes or install virtual network interfaces).

Basically, my vision of HIP is like a standardized version of Amicima, 
such as was just integrated into Flash by Adobe.

A VPN/virtual-interface over HIP would be really cool -- don't get me 
wrong.  It'd be like an open-source, standardized version of Hamachi. 
But as an application developer, I wouldn't ever ask my users to deploy 
some scary virtual tunnel just to use my thing.

Personally, I don't see any good reason not to use HIP.  It seems like 
such an obvious duplication of effort I don't understand why the IETF 
allows it.  Though admittedly I haven't followed it closely in the past 
few years.

-david

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 07:46:49 -0700

At Thu, 26 Jun 2008 13:40:39 -0400,
> questions about how to provide the best interface for applications using 

It seems to me that we're repeating ourselves. From the minutes
of PHL:

    The chairs called for consensus on the question "Should we ask that
    protocols developed allow HIP to be a customer of the P2Psip service,
    within the constraints of the charter?"  There was no opposition.
    
    The chairs called for consensus on the question "Should we structure
    the P2PSIP service such that hip is a) a mandatory part of the
    technical infrastructure b) an optional part of the technical
    infrastrcuture c) potentially present only when it replaces IP, with
    no other linkage.  Rough consensus for b as the current answer, with
    further discussion as the technical documents describing p2psip
    protocols progress.

Do we really need to rehash the discussions that led to this consensus
call?

-Ekr

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 27 Jun 2008 11:05:12 -0400

Hi, Ekr:

I do not think that we need to re-evaluate the consensus.

Rather we have to see "how" HIP is used in P2PSIP in view of the consensus.

BR/Radhika

----- Original Message -----
From: Eric Rescorla 
Date: Friday, June 27, 2008 10:47
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Bruce Lowekamp 
Cc: [email-masked], [email-masked], P2PSIP WG , [email-masked], Henry Sinnreich 

> The chairs called for consensus on the question "Should we ask 
> that protocols developed allow HIP to be a customer of the 
> P2Psip service,
> The chairs called for consensus on the question "Should we 
> structure the P2PSIP service such that hip is a) a mandatory 
> part of the

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 08:27:35 -0700

At Fri, 27 Jun 2008 11:05:12 -0400,
> Rather we have to see "how" HIP is used in P2PSIP in view of the consensus.

Well, for what it's worth: I can tell you what I believe the intention of 
the RELOAD authors to be:

- RELOAD provides a system that works without the use of HIP transport.
- RELOAD can be used to provide the rendezvous service that HIP needs.
- RELOAD supports pluggable transports and can therefore be used over
  HIP. In this case, some of the services that RELOAD provides natively
  might be outsourced to HIP. However, someone would need to write a
  new document to define a HIP transport.

-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 27 Jun 2008 13:14:02 -0400

Henry Sinnreich wrote:
> Please help me understand:
> 
> Since P2P SIP would run over HIP, the customer is P2P SIP, not the other way
> round as in the above. Just as SIP, RTP, etc. are customers of IP.
> 
> Was this a typo?
> 

No, one of the requirements for running HIP is a rendezvous service.  A 
P2PSIP peer protocol is capable of providing the rendezvous service that 
HIP requires to form connections.

That question is independent of whether the P2PSIP peer protocol is 
using HIP as its transport protocol.

Bruce

> Thanks, Henry
> 
> On 6/27/08 7:46 AM, "Eric Rescorla" <[email-masked]> wrote:
>

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 09:03:09 -0700

Correct, the Not Invented Here (NIH) syndrome is probably the main reason
why there are so many NAT traversal solutions around, instead of using HIP
for all applications, just like using IP for everything. It is a good
example how local optimization can be counterproductive to solving a common
problem. Maybe the SIP, MMUSIC, BEHAVE folks should get together with the
HIP folks and let us all know what/if they a have a problem with HIP and let
us all know what it may be.

Sources quoted on this list for HIP include those by Ari Keränen:
>> [1] http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-03.txt
>> [2] http://hip4inter.net/
>> [3] http://infrahip.hiit.fi/
>> [4] http://tools.ietf.org/id/draft-camarillo-hip-bone-01.txt

WG chairs and ADs: Please feel free to forward this to the AIB, IESG.
It would make an excellent topic for the General Session at the 72 IETF.
Please let us know how it goes.

Henry

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 11:07:36 -0700

At Fri, 27 Jun 2008 10:07:46 -0700,
> round as in the above. Just as SIP, RTP, etc. are customers of IP.

No.

As Bruce indicated in a previous message, HIP needs a rendezvous service,
and a generic P2P overlay like RELOAD can provide such a service. In that
respect, HIP would be a client of RELOAD, even if RELOAD itself ran
over ordinary IP.

-Ekr

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 10:22:55 -0700

Now help me understand this

> one of the requirements for running HIP is a rendezvous service.  A

HIP has been defined with a rendezvous server (RVS) in the HIP Rendezvous
Extension RFC 5204. Actually, one of the nicer properties is the
flexibility, since any node can act as a rendezvous server; that's more than
SIP can do.

What am I missing?

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 10:07:46 -0700

Was this a typo?

Thanks, Henry

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 12:06:06 -0700

At Fri, 27 Jun 2008 10:22:55 -0700,
> flexibility, since any node can act as a rendezvous server; that's more than

I haven't studies this RFC carefully, but it looks to me like
the rendezvous service is potentially distributed, but in
the sense that everyone can pick their own rendezvous server,
not in the sense that the rendezvous service is collectively
provided. This means that I need a real relationship with
my RVS (in a similar way that I might have one with my
SIP registrar). I need to know that it will be online whenever
I am or I will be unreachable.

The whole point of a distributed rendezvous service like that
provided by P2PSIP is that the various members of the overlay
collectively provide that service and as long as one of them
is up, the system works, thus removing the need for an explicit
service relationship with some server.

-Ekr

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 11:16:10 -0700

What am I missing?

Henry

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 27 Jun 2008 15:21:27 -0400

> flexibility, since any node can act as a rendezvous server; that's more than

Locating a capable (non-NATed) rendezvous server in a distributed 
environment without a centralized service provider is itself a 
non-trivial problem.

Additionally, even if you have obtained a rendezvous server, you still 
need a registration server (RFC5203).

A P2PSIP peer protocol provides both.

Bruce

---

From: "Dan York" <[email-masked]>
Date: Fri, 27 Jun 2008 21:59:48 +0000

Is it just me or is there a fundamental bootstrapping problem here?

It seems like P2PSIP needs to sit on top of HIP for the addressing HIP provides.... yet HIP may need to sort of sit on top of P2PSIP to use the rendevous and registration services of P2PSIP.

This does not seem to be possible.

Or am I just way too tired after a week of traveling and am missing something basic?

Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: Bruce Lowekamp <[email-masked]>

Date: Fri, 27 Jun 2008 15:21:27 
To:Henry Sinnreich <[email-masked]>
Cc:[email-masked], [email-masked], [email-masked],P2PSIP WG <[email-masked]>
Subject: Re: [P2PSIP] HIP for P2P SIP

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 15:25:10 -0700

At Fri, 27 Jun 2008 21:59:48 +0000,
> Is it just me or is there a fundamental bootstrapping problem here?

Not really. You just need to be able to connect to some nodes
without using the rendezvous service. 

> It seems like P2PSIP needs to sit on top of HIP for the addressing
> HIP provides....

Well, this certainly is not true. RELOAD will work fine without
HIP. In fact, the only currently specified modes are non-HIP,
though we anticipate it would be straightforward to do a HIP mode.

-Ekr

---

From: "Dan York" <[email-masked]>
Date: Fri, 27 Jun 2008 22:56:26 +0000

Eric,

Sorry, I should have been clearer in my statement:
------
*When used with HIP*, it seems like P2PSIP needs to sit on top of HIP for the addressing HIP provides....
------

I do realize that currently-proposed P2PSIP protocols will work fine without HIP.

Thanks for the info below,
Dan 

-----Original Message-----
From: Eric Rescorla <[email-masked]>

Date: Fri, 27 Jun 2008 15:25:10 
To:[email-masked]
Cc:"Bruce Lowekamp" <[email-masked]>,[email-masked],"Henry Sinnreich" <[email-masked]>,[email-masked],[email-masked],P2PSIP WG <[email-masked]>,[email-masked]
Subject: Re: [P2PSIP] HIP for P2P SIP

-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 29 Jun 2008 16:02:06 -0400

> Thanks for the info below,

Let's be a bit careful about what "when used with hip" means.  There are 
at least four cases:

a) P2PSIP overlay deployed in a pre-existing HIP environment
b) P2PSIP overlay deployed on a traditional IP network with applications 
using a pre-existing HIP environment
c) P2PSIP overlay providing rendezvous and lookup services for a HIP 
environment (presumably for other applications), but not using HIP for 
its connections
d) P2PSIP overlay providing rendezvous and lookup services for a HIP 
environment and using HIP for its connections

Case (a) works with any peer protocol that has been proposed since the 
peer protocol doesn't know it's using HIP.  In this event you could even 
deploy the peer protocol without ICE since HIP is doing the ICE 
negotiation for you.  (of course, you need to know this)

In case (b), if the resources stored in the overlay use HITs, neither 
the peer protocol nor the application need to be aware HIP is being used.

So those two cases of P2PSIP being used with HIP just work out of the 
box, no interactions, and IMHO no layering questions.

In case (c), the peer protocol is taking the place of other rendezvous 
and location services (DNS and a standalone HIP rendezvous application, 
for example).  I don't think there are any layering concerns here, it's 
just a different application being used to accomplish the same service.

For case (d), essentially what you have is the peer protocol forming an 
overlay on a partial graph of the HIP environment.  The peer protocol 
then uses its overlay as rendezvous server to add new edges between HIP 
nodes (either to the overlay or for other applications).  Is this a 
layering violation?  Well, without the peer protocol, HIP calls up to 
DNS and a rendezvous server to form connections.  With the peer 
protocol, the overlay provides those two services.  In both cases, an 
application layer service is being used to provide help to form the 
connection.

Now, is it a problem that messages may be sent over a HIP connection to 
provide this service to HIP?  Honestly, to me this looks an awful lot 
like OSPF, which uses IP encapsulation when sending packets between 
adjancencies.

Personally, I think from a purist's point of view HIP and P2P are both 
types of overlay networks, which naturally encompass some amount of 
layering violation if you take a pedantic view of the layers.  I don't 
find that any of the methods of using HIP with P2PSIP present 
substantially new layering issues.

Bruce

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 29 Jun 2008 15:15:36 -0700

> Is it just me or is there a fundamental bootstrapping problem here?

There is no bootstrapping problem with HIP.

See for example the just published
http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-03.txt
Henry

On 6/27/08 2:59 PM, "Dan York" <[email-masked]> wrote:

> It seems like P2PSIP needs to sit on top of HIP for the addressing HIP
> provides.... yet HIP may need to sort of sit on top of P2PSIP to use the
> rendevous and registration services of P2PSIP.
>

---

From: Ari Keranen <[email-masked]>
Date: Mon, 30 Jun 2008 13:43:33 +0300

> need a registration server (RFC5203).

Actually, in HIP you don't need a separate "registration server" to get 
rendezvous service but you use the registration extension (RFC5203) to 
register to the service. And for the NATed case you should use HIP relay 
service, i.e., instead of forwarding just the I1 as in RVS, whole base 
exchange is done trough the relaying service. This service can be 
provided by a relay server [1] or, e.g., a P2PSIP overlay [2].

Cheers,
Ari

[1] http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-03#section-3.1
[2] http://tools.ietf.org/html/draft-camarillo-hip-bone-01#section-3.2
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Ari Keranen <[email-masked]>
Date: Mon, 30 Jun 2008 17:40:50 +0300

Hi David,

> users to make TCP stack changes or install virtual network interfaces).

This should be doable. The application would need to be "HIP aware" 
(i.e., not use just the standard socket API) for this to work, but I 
suppose that's not a big problem. Or maybe we could link our app with a 
non-standard libc. To not require root rights for the program we would 
need to use UDP encapsulation, but then again, we need to do it for NAT 
traversal anyway. Also, it's worth noting that even the current 
implementations of HIP require no changes in the TCP stack.

It is true that installing some implementations of HIP is not at the 
moment as easy as it should be, but there are ongoing efforts to improve 
the situation. When/if HIP is (hopefully one day) provided natively by 
the major OSs, this won't be a problem anymore. Meanwhile, if we can 
make installing and enabling HIP (if not already available) as easy as 
clicking "yes" a few times when installing a program that needs it, I 
suppose we can live with it.

> some scary virtual tunnel just to use my thing.

Well, the users don't have to know about the scary tunnels :-) But 
seriously, I think the users won't really mind what is installed as long 
as the thing works and does not break anything. And if we run HIP over 
UDP and don't do any kernel tricks (which are usually done just to get 
better performance), using HIP doesn't really differ that much from 
using any other network protocol.

Cheers,
Ari

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 30 Jun 2008 16:03:38 -0400

> provided by a relay server [1] or, e.g., a P2PSIP overlay [2].

I think we must be in violent agreement, modulo a bit of terminology. 
Labeling 5203 as defining a "registration server" is a bit of an 
oversimplification, but I think accurately identifies one of the roles 
the overlay would have to fulfill.   And draft-ietf-hip-nat-traversal 
merely identifies HIP relay as another role (ice aware) for a rendezvous 
server.

I probably should have pointed to rfc5205 as well.

Anyway, the entire purpose of my email was to point out that something 
needs to fulfill these two roles, and as suggested by hip-bone and 
others, a p2psip overlay is well-suited for the job, particularly in an 
ad hoc environment (no provisioned servers or dns).  I think we both 
agree on that.

Bruce

---

From: Ari Keranen <[email-masked]>
Date: Tue, 01 Jul 2008 06:57:05 +0300

Bruce Lowekamp wrote:
>>> Additionally, even if you have obtained a rendezvous server, you 
>>> still need a registration server (RFC5203).
>>
>> Actually, in HIP you don't need a separate "registration server" to 
>> get rendezvous service but you use the registration extension 
>> (RFC5203) to register to the service. And for the NATed case you 
>> should use HIP relay service, i.e., instead of forwarding just the I1 
>> as in RVS, whole base exchange is done trough the relaying service. 
>> This service can be provided by a relay server [1] or, e.g., a P2PSIP 
>> overlay [2].
> 

Yes, we fully agree on that. I was just worried that some people on the 
list might get the impression that you need two different servers just 
to get the rendezvous service. Thanks for clarifying.

Cheers,
Ari