Subject: [Hipsec] Rendezvous Server Concerns

From: Kevin Grace <[email-masked]>
Date: Thu, 03 Feb 2005 13:50:15 -0500

After cogitating on the topic of Rendezvous Servers for HIP, some
concerns have emerged that should probably be discussed within the
WG. It seems that these concerns are pretty fundamental and may
ultimately limit the desire to pursue Rendezvous Servers.

 From reading draft-ietf-hip-rvs-00.txt, two reasons are given to
motivate the use of Rendezvous Servers. The first has to do with the
cost of resigning DNS zones after an update, the second has to do with
stale entries in caches being used to respond to queries...the
relevant pararaphs are:

   One drawback of using dynamic DNS updates in this way is the cost of
   updating secure zones.  Re-signing an entire zone whenever the IP
   addresses of one entry change places a high cost on the DNS server.
   Using dynamic DNS to update HI->IP mappings may thus not be
   appropriate when changes of IP addresses are frequent.
....
   Another concern with using the DNS to support HIP node mobility is
   the propagation time of updated DNS entries.  DNS servers frequently
   cache DNS responses to reduce the load on the primary servers.
   During the time-to-live associated with a DNS response, DNS servers
   may answer additional requests for the same DNS entry from their
   local caches instead of contacting the primary servers.  Thus, even
   after a HIP node updates its DNS entry, the DNS can still serve the
   old entry until the cached responses expire.  This can lead to
   communication problems, because peers may try to contact a HIP node
   at an IP address it is no longer reachable at.

The Rendezvous Server approach seeks to avoid sending dynamic updates
to DNS for mobile nodes and instead creates a new resource record type
in DNS that will allow HIP aware nodes to learn of the IP address(es)
or hostname(s) of a mobile node's relatively static Rendezvous Server.

It seems that this approach will prevent a mobile HIP node from being
reachable by *all* non-HIP nodes, whenever it moves and its current IP
address is not the IP address stored in DNS. This seems like an
unacceptable outcome. Does it not make more sense for the mobile node
to perform a dynamic DNS update so that it can be reached by non-HIP
nodes? And if that's the case, then doesn't the RVS become unnecessary
since its raison d'etre was to avoid dynamic DNS updates?

The second reason given to motivate the use of Rendezvous Servers was
to avoid cache staleness problems. It seems that this can be directly
solved simply by setting time-to-live values on mobile node resource
records to very small values...again, Rendezvous Servers seem
unnecessary.

Are there any compelling reasons to pursue Rendezvous Servers that
outweigh the loss of reachability that non-HIP nodes will experience?

Regards,
Kevin

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 3 Feb 2005 21:49:36 +0200

> unacceptable outcome.

Nothing prevents you from using some non-HIP mechanism to remain
reachable by non-HIP nodes.  For example, if you can arrange one
of your rendezvous servers (or some other node) to forward packets
to you and packets sent by you, i.e. what is sometimes called a
HIP proxy, you can certainly make your A / AAAA record to point
to that node.  But that is beyond the scope of core HIP, and
beyond the scope of the current WG charter.

Two questions:

- Have you read what the architecture draft says about rendezvous?
   Does that make sense to you?

   http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt

- Are you familiar with more advanced rendezvous concepts, like
   Hi3 or rendezvous-based NAT traversal?

   http://www.watersprings.org/pub/id/draft-nikander-hiprg-hi3-00.txt

Note that the advanced rendezvous issues are being discussed
at the *Research* Group side, as they go beyond the current WG
charter.

--Pekka Nikander

---

From: Kevin Grace <[email-masked]>
Date: Thu, 03 Feb 2005 15:57:48 -0500

Hi Pekka,

Thanks for the response. My comments are interspersed below...

> beyond the scope of the current WG charter.
So rather than just letting mobile nodes do dynamic DNS updates, you are 
suggesting a better alternative is to:
1) Implement and deploy rendezvous servers
2) Modify existing DNS implementations to support a new resource record 
type for the rendezvous server (doubtful that proprietary 
implementations would ever evolve to support it)
3) Specify, implement, and deploy HIP proxies (all of which are 
challenging) and then possibly suffer the resultant triangle based routing

Doesn't that seem like alot of effort just to avoid dynamic DNS updates 
from mobile nodes?

> - Have you read what the architecture draft says about rendezvous?

Yep.

>   Does that make sense to you?

No...not given that dynamic DNS updates appear to obviate the need for 
Rendezvous Servers. As for the problem of both nodes changing their 
addresses at the same time, HIP implementations could detect the loss of 
connectivity and query DNS for the peer's new IP address...

>   Hi3 or rendezvous-based NAT traversal?
Not really, though I did quickly skim the doc and honestly I don't see 
how it makes a compelling argument in support of Rendezvous Servers when 
someone wants to use HIP simply for the purpose of maintaining 
connectivity with mobile nodes.

Are there reasons beside not wanting to perform dynamic DNS updates that 
justify all the implementation and deployment costs that Rendezvous 
Servers seem to require?

Thanks,
Kevin

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 4 Feb 2005 10:11:20 +1300

On 4/02/2005, at 9:57 AM, Kevin Grace wrote:

> So rather than just letting mobile nodes do dynamic DNS updates, you 
> are suggesting a better alternative is to:
> 2) Modify existing DNS implementations to support a new resource 
> record type for the rendezvous server (doubtful that proprietary 
> Doesn't that seem like alot of effort just to avoid dynamic DNS 
> updates from mobile nodes?

Not if you want to support really low-latency mobility.  Personally, 
I've always thought of the RVS as being supplementary to dynamic DNS; 
use it when either you can't do a DNS update (for example if you're not 
routable, and the RVS is going to send you to a proxy) or you want it 
done too fast (in the middle of a VoIP call, for example).

> addresses at the same time, HIP implementations could detect the loss 
> of connectivity and query DNS for the peer's new IP address...

And lose connectivity for several seconds, at the very least.  RVS does 
take a few round trips, but in most of the cases of interest that's 
much better than seconds.
>
> Are there reasons beside not wanting to perform dynamic DNS updates 
> that justify all the implementation and deployment costs that 
> Rendezvous Servers seem to require?

Latency and providing some basics for the research group results to 
build on.

Andrew

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 4 Feb 2005 08:01:44 +0200

Trying to summarise, the WG motivation for rendezvous servers is
latency.  You just can't get sub-second (or even sub-10-second)
latencies from the DNS.  Going to anywhere below 30 minutes will
have DNS performance consequences that will make the DNS WG to
object, and possibly IESG to reject.

At the RG side, the situation is richer.  We have the new
possibilities, such as Hi3.  We have the need to act without
DNS names, i.e., using HITs as primary identity handles.
Thirdly, there is some tendency in seeking for alternatives
for the DNS.

>> updates from mobile nodes?

If you are saying that the requirements for added infrastructure
may make HIP deployment harder, you are certainly right.  To
mitigate or counter that argument, we have to consider the
following:

- You can achieve small scale HIP deployment without DNS.
   That is what is happening now.  People are using /etc/hosts
   to configure their peers' HITs.

- For wider scale early deployment, you need proxies anyway.

- There are concrete plans to deploy Hi3 in PlanetLab during
   this year.

--Pekka

---

From: Kevin Grace <[email-masked]>
Date: Fri, 04 Feb 2005 09:15:03 -0500

> object, and possibly IESG to reject.
Today, using readily available DNS implementations and without 
Rendezvous Servers, one can create an A record in an authoritative name 
server for a mobile host and assign it a time-to-live of 1 second. The 
longest the record could possibly be cached by non-authoritative name 
servers then is 1 second.When the node moves and changes IP addresses, 
it can successfully update its A record within the authoritative name 
server in less than a second. The total latency between when a node's 
address changes and when DNS is properly updated need not exceed a 
couple seconds and could well be closer to one second. This appears to 
be a perfectly legitimate usage of DNS. Why would the DNS WG or IESG 
have any authority or control over what an individual mobile node 
chooses for its time-to-live?

On the other hand, using Rendezvous Servers will require modifications 
to DNS to support a new resource record type...this would definitely 
require acceptance by the DNS WG and unless demand for HIP is high, 
proprietary implementations of DNS may never be modified regardless of 
acceptance for the modifications within the DNS WG. The prospects here 
seem much less certain than simply adjusting time-to-live fields.

>   to configure their peers' HITs.

One can achieve large scale HIP deployment without modifying DNS and 
without Rendezvous Servers. The HIP protocol appears to support optional 
certificates within the base exchange messages. By combining these 
certificates with HIP's opportunistic mode, there is a very simple and 
elegant way of obtaining a peer's host identity that is not vulnerable 
to man-in-the-middle attacks...and it doesn't require HIT's to be stored 
in DNS.

> - For wider scale early deployment, you need proxies anyway.

Not if you avoid using Rendezvous Servers...

HIP appears to be a wonderful mobility enabler and hopefully will be 
deployed widely. In order for that to happen though, it seems to make 
alot of sense to minimize the amount of complexity, effort, and 
acceptance which is required. Rendezvous Servers, modifying DNS, and HIP 
proxies seem to add lots of new challenges that are not really necessary 
in order for HIP to be widely deployable. The arguments in support of 
Rendezvous Servers (possibly reduced update latency, and "providing some 
basics for the research group results to build on") seem pretty thin; 
the arguments against them seem much more compelling...IMHO.

Regards,
Kevin

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 4 Feb 2005 17:45:43 +0200

Kevin,

> Rendezvous Servers, one can create an A record in an authoritative 
> name server for a mobile host and assign it a time-to-live of 1 
> second. The longest the record could possibly be cached by 
> non-authoritative name servers then is 1 second.When the node moves 
> and changes IP addresses, it can successfully update its A record 
> within the authoritative name server in less than a second. The total 
> latency between when a node's address changes and when DNS is properly 
> updated need not exceed a couple seconds and could well be closer to 
> one second.

This is very good news indeed.  Would you care to share us with a 
reference?

> This appears to be a perfectly legitimate usage of DNS. Why would the 
> DNS WG or IESG have any authority or control over what an individual 
> mobile node chooses for its time-to-live?

Well, I am certainly not a DNS expert.  However, I have been told that 
you SHOULD not use TTL less than 30 minutes, or you will cause bad 
performance.  But maybe all those people have been wrong.  Googling 
revealed the following paper, which seems to indicate reverse:

Performance and the Effectiveness of Caching, Jaeyeon Jung,  Emil Sit, 
Hari Balakrishnan,  Robert Morris Proc. ACM SIGCOMM Internet 
Measurement Workshop, 2001

http://nms.lcs.mit.edu/papers/dns-imw2001.html

But they "fast" TTL seems still to be a few hundred seconds?

> without Rendezvous Servers.
> The HIP protocol appears to support optional certificates within the 
> base exchange messages. By combining these certificates with HIP's 
> opportunistic mode, there is a very simple and elegant way of 
> obtaining a peer's host identity that is not vulnerable to 
> man-in-the-middle attacks...and it doesn't require HIT's to be stored 
> in DNS.

If what you indicate about DNS is true, I would certain agree.  OTOH, 
you still need a CA for that, but so do you need for many uses anyway.

> Not if you avoid using Rendezvous Servers...

Yes, you do, as you have to support legacy hosts.  They just don't work 
if you change your IP address dynamically.

> acceptance which is required.

I fully agree.

> Rendezvous Servers, modifying DNS, and HIP proxies seem to add lots of 
> new challenges that are not really necessary in order for HIP to be 
> widely deployable.

I'm afraid we can't avoid proxies, but it would be great if we could do 
without DNS modifications, and initially without rendezvous servers.

> The arguments in support of Rendezvous Servers (possibly reduced 
> update latency, and "providing some basics for the research group 
> results to build on") seem pretty thin; the arguments against them 
> seem much more compelling...IMHO.

If you manage to convince the DNS WG that zero or near-zero TTL A/AAAA 
records are fine, my guess is that there are very few if any members of 
this WG that insist on rendezvous servers.

--Pekka

---

From: Kevin Grace <[email-masked]>
Date: Mon, 07 Feb 2005 08:40:51 -0500

Pekka Nikander wrote:

>> latency between when a node's address changes and when DNS is 
>> properly updated need not exceed a couple seconds and could well be 
>> closer to one second.
>
>

Sure. From the London Communications Symposium in 2002:
    http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf

The authors in the referenced paper demonstrate empirically how fast DNS 
can perform zone transfers and the maximum update rate it can support 
for a given configuration. Note, they are using what today would be 
considered slow platforms (650 MHz PIII) and even better performance 
results can be obtained today. My own organization has conducted similar 
tests using faster hardware and have been able to support over 300 
individual dynamic updates/sec where each mobile node has a unique TSIG 
key; each individual update completes in well under a second.

> Yes, you do, as you have to support legacy hosts.  They just don't 
> work if you change your IP address dynamically.

No, legacy hosts can be directly supported without proxies and without 
Rendezvous Servers. If a mobile node moves and updates DNS with its new 
IP address, it can be reached by HIP aware and HIP unaware (legacy) 
nodes. Why do you think proxies are required?

Regards,
Kevin

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 8 Feb 2005 18:48:08 +0200

> Sure. From the London Communications Symposium in 2002...

Sounds interesting.  I'll return to this once I've read the paper.

> Why do you think proxies are required?

To me, mobility does not only mean reachability or initial rendezvous,
but also session continuity.  In other words, IP mobility means that
you can keep your active TCP connections running when you change your
address.  That's why.

--Pekka

---

From: Kevin Grace <[email-masked]>
Date: Tue, 08 Feb 2005 12:42:27 -0500

> you can keep your active TCP connections running when you change your

Session continuity is achievable without proxies. In the case where only 
one of the HIP peers moves at a time and changes its address, the mobile 
node can readily send a HIP UPDATE to its peer (whose address has not 
changed) to indicate its new IP address, thus maintaining all existing 
transport layer sessions between them. In the more challenging case 
where both nodes move simultaneously and change addresses, upon 
detecting that HIP UPDATE messages are not getting ACK'd, a node can 
query DNS for the peer's new IP address and then proceed to send HIP 
UPDATE messages to the peer at the new address. This seems like a pretty 
straightforward modification to a HIP implementation...and it doesn't 
require proxies. The only requirement is for mobile nodes to dynamically 
update DNS.

There are some additional pertinent details to this approach. One is: 
how does a HIP implementation learn a peer's hostname? This can be done 
in a variety of ways. One promising way is for a hostnames to be 
included in the optional CERT's during the base exchange.

The nice thing about using CERT's during the base exchange is not only 
does it allow hostnames to be exchanged (which enables the above 
solution to the problem of both peers simultaneously moving) but it also 
allows HI's to be exchanged in "opportunistic mode" without exposing 
either to a man-in-the-middle attack. And since HI's can be securely 
exchanged, there is no longer a need to modify DNS to store HIPHI (as 
well as HIPRVS) records.

Regards,
Kevin

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 9 Feb 2005 06:12:37 +0200

> Session continuity is achievable without proxies.

Towards legacy nodes?  Remember, it was communication between HIP and
legacy nodes that we were discussing about in the context of proxies.

For HIP double jump you may still want to have HIP *rendezvous*
servers, not proxies, or perhaps you can come along without, as you
suggest.  But I am getting a feeling that you are personally stuck
to the idea of using the DNS.  I agree that the DNS would be one
nice alternative, provided that it works, which remains to be seen.
OTOH, I don't think either rendezvous or DNS are a panacea; more
probably both are needed.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Wed, 9 Feb 2005 10:18:09 +0200 (EET)

> require proxies. The only requirement is for mobile nodes to dynamically

If we talk about implementation stuff, I think you don't want to *require*
the dependency on DNS. For example, the HIPL implementation is completely
kernel based and you generally don't want to do DNS look-ups from the HIP
module in such an implementation.

According to the layering principle, it is better to keep the HIP layer
independent from the "DNS layer" (i.e. application layer) after the
initial contact.

I haven't considered NA(P)Ts yet. Is there an advantage of using DNS vs.
rendezvous with NATs?

> included in the optional CERT's during the base exchange.

The HI can already include the hostname.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Wed, 09 Feb 2005 10:33:39 +0100

Hi Kevin,

Please find my answer inlined below,

On Friday 04 February 2005 15:15, Kevin Grace wrote:
> On the other hand, using Rendezvous Servers will require
> modifications to DNS to support a new resource record type...this
> would definitely require acceptance by the DNS WG and unless demand
> for HIP is high, proprietary implementations of DNS may never be
> modified regardless of acceptance for the modifications within the
> DNS WG. The prospects here seem much less certain than simply
> adjusting time-to-live fields.

Using Rendezvous Servers does not require to modify DNS per se. You 
can use a Rendezvous Servers (1) without DNS, (2) with non-HIP-aware 
DNS, and (3) with HIP-aware DNS.

In (1), you are not using DNS so you supposedly gain knowledge of the 
IP address of your peer by out-of-band means. Hence, you're likely to 
be in position to also obtain the peers's HI/HIT, and possibly its 
RVS IP address.

In (2), you are using non-HIP-aware DNS, hence you can resolve a FQDN 
into an A/AAAA RR. The A/AAAA record can also be used to store the 
RVS IP address, provided it is returned as the last RR in the RR set. 
The AAAA record can also be used to store the HIT (or IPv6 LSI), 
still if it is returned as the last RR in the RR set.

In (3), you use A, AAAA, HIPHI and HIPRVS to store the appropriate 
informations.

In both (2) and (3) you can still use DynDNS. RVS may is usefol when 
the scenario includes highly mobile or NATed nodes, or a more 
elaborated rendezvous architecture (ala Hi3).

> One can achieve large scale HIP deployment without modifying DNS
> and without Rendezvous Servers.

That's why the rendezvous server protocol and DNS extensions are in 
separate documents and not in the base protocol.

> HIP appears to be a wonderful mobility enabler and hopefully will
> be deployed widely. In order for that to happen though, it seems to
> make alot of sense to minimize the amount of complexity, effort,
> and acceptance which is required. Rendezvous Servers, modifying
> DNS, and HIP proxies seem to add lots of new challenges that are
> not really necessary in order for HIP to be widely deployable.

I am quite sure nobody in the WG would object if you choose to use HIP 
without rendezvous servers and without using the DNS extensions. 
These are optional components of HIP and are not required per se to 
use HIP. 

Even if you don't support RVS you should still be able to contacts 
nodes staying behind a RVS if you know their IP address or those of 
the RVS. The RVS protocol has been designed to be mostly transparent 
to Initiators.

If you don't support DNS extensions you can store your IP addresses in 
A/AAAA RRs, and the HITs in the last AAAA RR returned in a set (yes, 
this is a hack).

Thanks,

--julien

---

From: Kevin Grace <[email-masked]>
Date: Wed, 09 Feb 2005 09:22:03 -0500

> legacy nodes that we were discussing about in the context of proxies.

Perhaps if there was a draft on the HIP proxy, some of the discussion 
here about its purpose and functionality would be simpler. An earlier 
part of this thread seemed to indicate that HIP proxies were intended to 
make HIP nodes behind an RVS be reachable by legacy nodes. Now it seems 
that proxies are intended to allow mobile HIP nodes to maintain sessions 
with stationary legacy nodes regardless of whether RVS's are present. 
The former purpose, by itself, did not seem compelling enough to warrant 
the creation of HIP proxies if simply by avoiding RVS's the problem went 
away. On the other hand, the latter purpose seems to have alot of merit 
as one can envision numerous cases where it would be useful to maintain 
sessions between legacy nodes and mobile HIP nodes.

Is a draft description of HIP proxies on the horizon?

Is it envisioned that HIP proxies will be able to maintain sessions 
between legacy nodes and mobile HIP nodes without the existence of an RVS?

> probably both are needed.
You may be right. If one really needs sub-second mobile update 
latencies, then RVS's may be warranted. If, on the other hand, one can 
get by with one second update latencies, then the additional RVS 
requirements of a HIP proxy server (for legacy node connectivity) and 
modifications to DNS for the HIPRVS records seem pretty steep.

Thanks for the discussion.

Kevin