Subject: A roadmap for end-point identifiers? (was Re: where the indirection layer belongs)

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Sep 2003 11:52:32 +0300

[Please direct replies either to the IPv6 or the IETF
mailing lists, but not both.  The default should be IPv6,
imho.]

Pekka Nikander wrote:
 >> Now, even though I believe that we should solve the problems (and
 >> apparently believe that there are sensible solutions), achieving
 >> consensus on solutions that require architectural change may take too
 >> long.  Hence, I also believe that we need some kind of a road map,
 >> with some "temporary" or intermediate solutions along the way to a
 >> more long-standing set of solutions.

Robert Honore replied:
 > I agree, and your statement corresponds to what Keith Moore says about
 > the solutions fitting into a framework that is yet to be specified.  I
 > believe specification of that framework begins with our defining
 > what an end-point is.

Good that we agree on a need for a roadmap.  Now, I want to return
back to your original problem analysis:

 > *    Stable (or reliable) end-point identifiers
 > *    Resiliency of application (protocol) in the face of sudden
 >      IP address changes
 > *    Self-organised networks

These are the goals that we need to focus on.  While designing
the longer term architectural solutions, we need to preserve
the current functionality, and think about transition mechanisms.
 From this point of view, the only (semi-)stable end-point
identifiers we have today are IP addresses.  We both agree, and
I think quite a few others agree, that IP addresses are not very
good end-point identifiers.  However, they are used as such today.

Furthermore, it will take quite a long time to get something to replace
the IP addresses as end-point identifiers.  As has been discussed
several times, domain names do not work well enough, and therefore
we need a new name space, I think.

Consequently, we have to provide (semi-)stable IP addresses
for IPv6 networks.  Based on the recent discussion at the IPv6
WG, apparently people think that PA addresses are not stable
enough.  Hence, at least to me, the Hinden/Haberman addresses
look like a good temporary solution.  It seems to provide stable
IP addresses, which can temporarily be used as end-point identifiers,
with the expectation that they will be eventually replaced with
"proper" end-point identifiers.

What comes to application resiliency, Christian Huitema's
approach of (mis)using Mobile IP may work well enough for a while.
However, it has a number of architectural problems that make
me to think about it only as a temporary solution.  Going further,
if we did not have any other reasons for "proper" end-point
identifiers, I think that Dave Croker's MAST might be good next
step.  However, since I do think that we most probably do need
stable and secure end-point identifiers, I think that something
like HIP will be more appropriate.

[I'm relatively ignorant to the exact details of self-organized
  networks, and therefore I don't want to comment that.]

Given the above, I think we could have a roadmap that might
look something like the following:

  Stable identifiers:    Hinden/Haberman -------------> New name space
                                                        for end-point
  Resiliency on          Huitema MIPv6  --> (MAST) ---> identifiers
  address changes:       multi-homing                   (maybe HIP)

--Pekka Nikander

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Sep 2003 12:09:25 +0200

On maandag, sep 8, 2003, at 10:52 Europe/Amsterdam, Pekka Nikander 

> mailing lists, but not both.  The default should be IPv6,

As IETF seen a lot of this stuff recently already, why not move the 
show to IPv6... Note also that multi6 is doing work in this area.

> These are the goals that we need to focus on.

> identifiers we have today are IP addresses.

Don't forget about FQDNs.

> We both agree, and

The trouble isn't that IP addresses don't make for good end-point 
identifiers or that they don't make for good topology/interface 
identifiers, but that they can't do both at the same time.

Today, a host has an IP address that is both present in the DNS in 
order to be usable as an identifier, and present on an interface to be 
usable as a locator. We can either keep the address we have in the DNS 
and create new locators, or create a new identifier that goes into the 
DNS and keep the current address(es) as locators.

> we need a new name space, I think.

What exactly do you mean here? A 128 bit value that we can put in all 
the right places inside the applications and transport protocols (but 
not on the wire), or something that isn't such a 128 bit value?

> "proper" end-point identifiers.

One very important property of identifiers is that they have enough 
structure to be used as a key in a lookup process. I haven't seen a 
write-up of HH addresses, but from what I understand they lack this 
property.

And note that the use of non-routable, stable addresses isn't free: you 
need to go through a lookup process to find the locators. If you use 
reachable PA as identifiers you have the option of connecting first and 
adding multihomedness later. And you probably need PA for a while 
anyway to support legacy IPv6 implementations or even as a fallback for 
when the new mapping system is unavailable.

> step.

Actually I think MAST is very close to mobility, and could, if 
developed further, easily replace what's on the table now for mobility, 
while at the same time attack the multihoming problem, for which 
current MIPv6 doesn't provide many useful hooks.

> However, since I do think that we most probably do need

Doing crypto all the time isn't the answer.

>  address changes:       multi-homing                   (maybe HIP)

The way I see it:

1. Define a generic address mangling system between IP and transports 
based on stable host identifiers OR simple session identifiers
2. Make no assumptions about the identifiers except that the transports 
must understand them, so: PA, PI/non 2000::/3 or even IPv4
3. Define mechanisms to populate the hostid/sesid+mangling table. Can 
be:
   a. out of band using distributed lookup database
   b. using in-band negotiation (= like MAST)
   c. crypto: modified IPsec or HIP

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 09 Sep 2003 11:16:31 +0300

Iljitsch,

[There is background meta discussion going on on where
  this discussion should be located at.  However, since one
  specific point here is site local, maybe we can keep this here
  for a while.  On the other hand, if this moves (again) completely
  to the multi-homing/mobility side, multi6 might be more appropriate,
  and chairs there have indicated that it would be ok.]

> identifiers, but that they can't do both at the same time.

Well, almost but not quite.  We also have the limitations of
the current routing technology, which make IP addresses really
suitable only as topology/network/interface identifiers.

> not on the wire), or something that isn't such a 128 bit value?

Well, my current personal opinion is that actual end-point identifiers
should most probably be cryptographic in nature, due to a number
of security reasons.  On the other hand, I also think that we need
some way of representing those end-point identifiers as 128- or
even 32-bit value, to be used in legacy APIs and withing the stack
(but probably not on the wire).  It is the a third issue whether
we want to use the cryptographic nature of the actual identifiers
in all transactions.  Probably not: sometimes using them just as bit
strings is likely to be appropriate.

Now, when I say that "end-point identifiers replace IP addresses",
I am mostly speaking about the semantic change.  In a way, already
using Mobile IPv6 route optimization presents such a semantic change,
though in very primitive form.  Using stable PI addresses locally
to name hosts for administrative purposes might be another primitive
example of such a semantic change.  On the other hand, the real
change only occurs when the end-point identifiers cease to be
IP addresses; MIPv6 RO and PI addresses both fail on this test.

I think Robert Honore put much of the need for end-point identifiers
very nicely in his recent posting to the general IETF discussion list. 
End-point identifiers are needed for many administrative purposes,
to permanently name hosts, services, and other end-point-like entities.

What comes to domain names, my primary concern is their lack of
security, and DNSsec does not seem to be the answer.  There
are also other problems with DNS names, including the difficulties
of integrating DynDNS and DNSsec, long update times (due to caching),
dependency of centralized (hierarchical) administration, etc.

> One very important property of [end-point] identifiers is that they
> have enough structure to be used as a key in a lookup process.
> I haven't seen a write-up of HH addresses, but from what I
> understand they lack this property.

Well, my (perhaps poor) understanding from the FARA work (by Bob
Braden, Aaron Falk and others) seems to indicate that it may be
perfectly OK to use identifiers even if they cannot be used
as keys in a lookup process.  However, my thinking process is
still going on, and I can't give any real argument here.

On the other hand, my (again poor) understanding from the recent
Distributed Hash Table papers seems to indicate that it is fairly
easy to use random strings as lookup keys in a distributed,
Byzantineously robust lookup system.  It even looks possible that
such a system could be built in a piece wise manner, letting it
scale up in a "natural" way.

Thirdly, nothing prevents one from arranging the identifier
space in such a manner that they can be used as hierarchical
lookup keys whenever such a lookup process is needed.  I think
that should be possible even for Hinden/Haberman addresses,
since such a lookup system would have limited scope.

> need to go through a lookup process to find the locators.

Using any address-independent identifiers or names costs something.
On the other hand, if you use the domain name system anyway, you can
make a  single query to get both the end-point identifier and a set
of locators.

> If you use reachable PA as identifiers you have the option
> of connecting first and adding multihomedness later.

Yes, provided that your PA address works, right now.  Which is one
dependency that we are trying to avoid.  Let me take a counterexample.
If you use PI addresses locally for administrative purposes (think SSH),
you can use them even if your network is disconnected, going through
renumbering, or otherwise failing to get any PA prefixes.

> And you probably need PA for a while anyway to support legacy
> IPv6 implementations or even as a fallback for when 
> the new mapping system is unavailable.

I don't see PAs going away any soon if ever, even at the
application level.  There are good reasons for still sending
UDP packets and even sometimes opening TCP connections to PA
addresses even if we had stable, reliable, address and location
independent end-point identifiers.

> Actually I think MAST is very close to mobility, and could, if developed 
> further, easily replace what's on the table now for mobility, while at 
> the same time attack the multihoming problem, for which current MIPv6 
> doesn't provide many useful hooks.

Sure it could.  In perhaps 4-5 years.  MIPv6 is here, now.
Again, what I am basically saying is that we seem to need a
roadmap, with short term solutions and longer term solutions.

> Doing crypto all the time isn't the answer.

Doing crypto all the time isn't the answer, I agree.  But you
do need crypto for some things, unfortunately.  Separating the
locators and end-point identifiers creates a number of very concrete
and nasty security problems, at the IP layer.  That is, those
problems are NOT application level security problems, but threats
to the well functioning of the very infrastructure.

http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt
tries to explain the most important ones of these problems.

> based on stable host identifiers OR simple session identifiers

This, as such, is already a long term goal, in my opinion.  Since
this is likely to require code changes, just deployment alone is
likely take a long time, not counting the time needed to reach
consensus at the IETF.

> must understand them, so: PA, PI/non 2000::/3 or even IPv4

Sorry, but I don't understand what you are trying to say.
Are you trying to say that we need to have 128 and 32 bit handles
so that they can be used by legacy applications and APIs?
If so, I do agree.

> 3. Define mechanisms to populate the hostid/sesid+mangling table. Can be:

Hmm.  It may be a good idea to have multiple mechanisms to get
the identifier->addresses mappings.  However, it would be good
if we had just a single control protocol and security mechanism
for verifying that the mappings are "authorized" and do not endanger
the infrastructure.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Sep 2003 11:45:58 +0200

Hi Pekka,

On dinsdag, sep 9, 2003, at 10:16 Europe/Amsterdam, Pekka Nikander  

> suitable only as topology/network/interface identifiers.

I don't think IP addresses are inherently unsuitable as identifiers.  
But obviously they are locators. So if we want to separate the two  
functions, either we invent a new "thing" to provide either one of  
these functions or we need identifier IP addresses and separate locator  
IP addresses.

> (but probably not on the wire).

So the 128/32 bit representation wouldn't _be_ the identifier but only  
a representation?

> It is the a third issue whether

I can't give you my opinion on this just yet because I don't have one,  
except that I'm not a huge fan of using crypto if not absolutely  
necessary.

> IP addresses; MIPv6 RO and PI addresses both fail on this test.

Are you saying that we should make a clear distinction between  
identifiers and locators, and not have any values that are valid in  
both realms? IMO, having an identifier that can also be used as a  
locator is a big plus, since that way you can be compatible with legacy  
operation without much effort and you can defer expensive operations  
necessary to actually do multihoming until the time you need it, i.e.  
when the identifier isn't reachable as a locator anymore.

Yes, this is somewhat messy but all the best things in life are.  :-)

> security,

How bad is this exactly? I know it was possible to play all kinds of  
nasty DNS tricks in the past (see the alternic pranks) but I think  
that's not the case anymore. I think the only way to fool the DNS is  
spoofing replies which is very difficult unless you can sniff the wire.

> and DNSsec does not seem to be the answer.  There

Yes, the DNS is ready for an overhaul, but I don't see it happening any  
time soon as this means global agreement, unlike simple stuff such as  
id/loc separation which can be done by two consenting endpoints.

>> have enough structure to be used as a key in a lookup process.

I didn't mean to say that they all have such structure, but whether or  
not they do is a very important property.

> as keys in a lookup process.

I'm sure it's possible to build something like that, but I do we want  
to? Not being able to do such lookups makes everything much harder,  
maybe even to the point of having to use yet another layer of  
indirection.

> Byzantineously robust lookup system.

Ok, not sure what you mean by "byzantineously robust" exactly and maybe  
I've missed a few of those papers, but so far nobody has been able to  
explain to me how you can build a DHT system using untrustworthy nodes.  
The best you can do is replicate the data to such a degree that it  
becomes very unlikely that all the nodes that hold the data collude to  
deceive you. If you think the DNS is bad, consider having a system  
where you need to depend on random strangers to be reachable...

> since such a lookup system would have limited scope.

For administratively assigned address space this isn't a problem, but  
for randomly chosen address space it is.

>> And note that the use of non-routable, stable addresses isn't free:  
>> you need to go through a lookup process to find the locators.

> make a  single query to get both the end-point identifier and a set

You would think that, wouldn't you?  :-)  But it starts to look like we  
need FQDN -> id -> loc so this would add an extra lookup.

> Yes, provided that your PA address works, right now.

It does _most_ of the time. And if your locator doesn't work you're in  
for a timeout anyway, whether it overlaps with the identifier or not.

> Which is one dependency that we are trying to avoid.

Obviously it should still work if the PA address is unreachable.

Note that systems that negotiate in-band, such as MAST or IPsec, need  
the original address to be reachable.

> Let me take a counterexample.

So you're saying: use PI first, PA as fallback? The problem is then  
what you put in the DNS. If the PI addresses are recognizable as such,  
we get to try PA first and fall back on PI if PA doesn't work, so there  
is no harm in having PI in the global DNS. With multihoming it's even  
better because then you can have a logical connection to PI while using  
the PA du jour.

>> developed further, easily replace what's on the table now for  
>> mobility, while at the same time attack the multihoming problem, for  
>> which current MIPv6 doesn't provide many useful hooks.

> Sure it could.  In perhaps 4-5 years.  MIPv6 is here, now.

Really? Where is it implemented then?

> roadmap, with short term solutions and longer term solutions.

Sure.

> tries to explain the most important ones of these problems.

Sorry, too long for a full read, and nothing really jumps out doing a  
quick scan.

> likely take a long time, not counting the time needed to reach

Not sure what your point is. Yes, the IETF is slow, and yes, this needs  
code.

>> 2. Make no assumptions about the identifiers except that the  
>> transports must understand them, so: PA, PI/non 2000::/3 or even IPv4

> so that they can be used by legacy applications and APIs?

Yes. However, we don't have "legacy" APIs as those are the only APIs we  
have. Another point is/was that locators and identifiers may overlap.

> for verifying that the mappings are "authorized" and do not endanger

The control protocol IS the mechanism. Rather than spend a few years  
trying to make one that is all things to all people, I think we should  
start by making the simplest one we can possibly make and let everyone  
who feels they can do better have a go after that.

I'm not worried about security as these are end-to-end mechanisms. If  
two hosts feel they don't have to protect their communication, who are  
we to say that they must? If you feel a mechanism is too insecure,  
either slap some additional IPsec or TLS on top of it, or don't use the  
mechanism.

Iljitsch

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 10 Sep 2003 16:00:55 +0300

Iljitsch,

>> ...  I also think that we need
>> even 32-bit value, to be used in legacy APIs and withing the stack...
> 

Yes.  See draft-moskowitz-hip-arch-03.txt for more reasoning
behind this.  But the basic reason for this is security, as
I mentioned above.  See also below.

>> I am mostly speaking about the semantic change. ...
> 
> both realms? 

Yes, in the long run.  In the short run, we probably have to
continue living in a world where there is no clear distinction
between the two.

I do understand your point about the benefits of an identifier
also being a locator, but I also believe that the benefits of
clean separation will more than pay the drawbacks in the long run.
(I don't have any analysis or data to support this belief, though.)

> How bad is this exactly? 

The problems become worse when you add mobility.  See below.

> where you need to depend on random strangers to be reachable...

With byzantine robustness I am more or less referring to the principles
that Radia Perlman used in her PhD these.  I think others have used
the same principles before, but I am most familiar with Radia's work.
It must be noted, though, that Radia used the term in the context of
routing protocols, while here we are dealing with DHT directory
services.

The basic assumption in byzantine robustness is that as long as the
number of dishonest participants do not exceed a treshold ratio
(e.g. one third of all participants), the system does not fail.

In the case of DHT servers, the more servers there are, the less
likely it is that the treshold would be exceeded.  Hence, even if
you are relying on strangers, you are relying on them in a random
manner, making any collusion highly unlikely, and impossible in
practise.

> for randomly chosen address space it is.

If we need a global directory, then yes.  However, if the directory
only needs to deal with locally assigned "identifiers" (as in the
case of Hinden/Haberman addresses), I don't see why it should be
a problem.

> It does _most_ of the time. ...

If you restrict your thinking to multi-homing, then yes.  But if
you add mobility, the situation is not that simple any more.

> So you're saying: use PI first, PA as fallback? 

I am saying that depending on application.  When I last time used
to run networks, I used different DNS names for administrative
purposes (the "real" host names if you will) and for giving out
to the users (the "service" names).

>> ....  MIPv6 is here, now.

E.g. http://www.mipl.mediapoli.com/.  I think KAME will soon
have it, too, if not already now in the snapshots.

>> http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec- 
>> 01.txt  tries to explain the most important ones of these problems.
> 

Ok, some excerpts below.

> who feels they can do better have a go after that.

I am always in favour of beauty contests and market evaluations.

> we to say that they must? 

We need to protect the infrastructure.  As I wrote, the danger is not
that mcuh to the communicating hosts but to the infrastructure.

Some excepts from the above mentioned draft:

2.1 Target

    Basically, the target of an attack can be any node or network in the
    Internet (stationary or mobile). The basic differences lie in the
    goals of the attack: does the attacker aim to *divert* (steal) the
    traffic destined to and/or sourced at the target node, or does it aim
    to cause denial-of-service to the target node or network. The target
    does not typically play much of a active role attack. As an example,
    an attacker may launch a denial-of-service attack on a given node A
    by contacting a large number of nodes, claiming to be A, and
    subsequently diverting the traffic at these other nodes so that A is
    harmed. A itself need not be involved at all before its
    communications start to break. Furthermore, A is not necessarily a
    mobile node; it may very well be stationary.

3.1.2 Stealing addresses of stationary nodes

    The attacker needs to know or guess the IP addresses of both the
    source of the packets to be diverted (A in the example above) and the
    destination of the packets (B). This means that it is difficult to
    redirect *all* packets to or from a specific node because the
    attacker would need to know the IP addresses of all the nodes with
    which it is communicating.

    Nodes with well-known addresses, such as servers and those using
    stateful configuration, are most vulnerable. Nodes that are a part of
    the network infrastructure, such as DNS servers, are particularly
    interesting targets for attackers, and particularly easy to identify.

> If you feel a mechanism is too insecure,  

Unfortunately neither IPsec nor TLS pixie dust helps here.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Sep 2003 02:33:06 +0200

Pekka,

On woensdag, sep 10, 2003, at 15:00 Europe/Amsterdam, Pekka Nikander 
wrote:

>> Ok, not sure what you mean by "byzantineously robust" exactly and 
>> maybe  I've missed a few of those papers, but so far nobody has been 
>> able to  explain to me how you can build a DHT system using 
>> untrustworthy nodes.  The best you can do is replicate the data to 
>> such a degree that it  becomes very unlikely that all the nodes that 
>> hold the data collude to  deceive you. If you think the DNS is bad, 
>> consider having a system  where you need to depend on random 
>> strangers to be reachable...

> (e.g. one third of all participants), the system does not fail.

Ok, I'm going to read up on this stuff but in the mean time: it's 
pretty obvious that if you want to be sure that a certain node doesn't 
deceive you, you must check with a significant number of different 
nodes to see if they agree. This is going to cost you performance.

> manner, making any collusion highly unlikely, and impossible in

I just don't see it happening. If we reach a million multihomers, 
900,000 of which are SOHO/private persons at some point in the future, 
and every piece of information is replicated in 10 places, there is 
still a 35% chance that a fortune 500 company has to rely on "basement 
multihomers" exclusively for this incredibly sensitive stuff. And 
remember: no SLAs, nothing.

I think we need some experimentation first. Maybe set up a "shadow DNS" 
that uses DHT?

> you add mobility, the situation is not that simple any more.

Yes, mobility is complex. But don't you have the home agent as a 
fallback? So even in this case the regular PA home address should work 
most of the time.

>>> If you use PI addresses locally for administrative purposes (think  
>>> SSH), you can use them even if your network is disconnected, going 
>>> through renumbering, or otherwise failing to get any PA prefixes.

> I am saying that depending on application.

No, that's no way to build something reliable. Either you always first 
do PA and only use the potentially non-routable addresses as a 
fallback, or you need two faced DNS or complex IGP tricks.

>>  two hosts feel they don't have to protect their communication, who 
>> are  we to say that they must?

> that mcuh to the communicating hosts but to the infrastructure.

I'm not sure what you mean. Routers? DNS servers?

>    As an example,
>    harmed.

Not really big news. And yes, it would be extremely helpful if we could 
do something about this, as this kind of stuff is really getting out of 
hand these days, with all those worms, scanning and DoS. But it has 
nothing to do with multihoming, mobility or IPv6.

> 3.1.2 Stealing addresses of stationary nodes

[...]

>    interesting targets for attackers, and particularly easy to 

If we use the DNS for multihoming we have to accept a certain risk of 
DNS corruption. Fortunately, we don't have to argue about how bad the 
risk is and whether it's acceptable or not, because we already take it 
by using DNS names. So if we're vulnerable because we use the DNS once, 
(name -> address) there is no substantial additional harm in doing it a 
second time (identifier -> locators).

>> If you feel a mechanism is too insecure,  either slap some additional 
>> IPsec or TLS on top of it, or don't use the  mechanism.

> Unfortunately neither IPsec nor TLS pixie dust helps here.

It does if you use it right.  :-)

For instance: why bother making all kinds of complex systems to protect 
binding updates? If I'm communicating with node A and I get a packet 
from address B claiming to be node A, I simply install B as an 
additional locator address for A if the packet passes ESP 
authentication for an SA that's negotiated with A.

On the other hand, if your binding mechanisms can be corrupted by an 
attacker, running IPsec or TLS doesn't help because it doesn't 
magically get the wrongfully redirected packets back to where they 
should have been in the first place.

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 11 Sep 2003 09:22:29 +0300

Iljitsch van Beijnum wrote:

> Ok, I'm going to read up on this stuff but in the mean time: it's pretty 
> obvious that if you want to be sure that a certain node doesn't deceive 
> you, you must check with a significant number of different nodes to see 
> if they agree. This is going to cost you performance.

It is going to cost some performance, I agree.  However, if you
arrange your data so that it is self authenticating, then the only 
reason for byzantine robustness is protection from DoS and negative
answers.  That is, if you can arrange your data so that if you do
receive a positive response, you can check that the response is
genuine, then the task is somewhat simplified.

Whether you can arrange your data to be self authenticating or not
depends on many factors.  One factor is whether your primary identifiers
are cryptographic in nature or not.

> remember: no SLAs, nothing.

I do understand your view.  But I don't share it.  I am sure
someone will sooner or later produce a statistical analysis
that can be used to quantify the danger.

We have to remember that even if we took the very simplistic
approach and distributed the data over all of those basement
servers, data about each separate identifier would be located
on different basement servers.  Furthermore, the exact set of
servers serving data about a particular identifier would be
extremely dynamic, since hosts would be joining and leaving
the DHT service network all the time.  Hence, even though I
agree that such an arrangement might scare pants off from an
IT manager, it might actually work extremely well and be extremely 
robust in practise.

> I think we need some experimentation first. Maybe set up a "shadow DNS" 

Excellent idea.  I wish I had more time to study the few ongoing
DHT experiments that there are.

> fallback? So even in this case the regular PA home address should work 

Well, yes, you would need some kind of a "home" agent for rendezvous.
However, if you bind your identity to your initial rendezvous
server, you create an additional single point of failure.  That
happens to be one of the problems with the current MIP and
MIPv6 practises.

On the other hand, if you do separate your identifiers and
locators, you can move around your "home" servers, or even
have multiple of them, thereby increasing resiliancy.

> do PA and only use the potentially non-routable addresses as a fallback, 
> or you need two faced DNS or complex IGP tricks.

I agree that you need two faced DNS.  I don't see any specific
reason why you should always do PA first and then PI, or vice
versa.  You do feed the DNS names to your applications anyway, and
you can do what I proposed (before you have real identifiers),
if you wish.  That is one reason why I see some value of using
PI addresses temporarily (for 3-5 years or so) as identifiers.
And that is one reason why I understand that many network
managers would like to have them.

Personally, I don't much like PI addresses.  IMHO, they seem to
create more complications than solve.  However, as a step towards a
proper separation of identifiers and locators, they are probably
needed.  Not by me, but by many network managers.

>> that much to the communicating hosts but to the infrastructure.
> 

All end-hosts and all subnets.  Basically, everything.

> Not really big news. ... But it has nothing to do with multihoming,
> mobility or IPv6.

It may not be big news, but it was news back when MIPv6 was at
the IESG for the first time.  And yes, what I am writing about
has everything to do with mobility and multi-homing.  And perhaps
even IPv6.

> It does if you use it right.  :-)

I think it is better to take this part off-line until you lose
your illusions about fairies being real :-)

--Pekka

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Sep 2003 16:33:38 +0200

On donderdag, sep 11, 2003, at 08:22 Europe/Amsterdam, Pekka Nikander 
wrote:

[DHT dangers]

> that can be used to quantify the danger.

Ok there is much more to say about this subject but it's probably 
better to do that when there is something concrete on the table.

>> No, that's no way to build something reliable. Either you always 
>> first do PA and only use the potentially non-routable addresses as a 

> versa.

Well, because if you try PA first and use PI only as a fallback you 
_don't_ need two faced DNS, which I think is evil.

> You do feed the DNS names to your applications anyway, and

Actually I see PA addresses being used in the short term because that 
makes the transition from existing IPv6 to the loc/id system easier. If 
you use PI identifiers then legacy hosts can't connect to them. Of 
course it's also possible to combine the two: use PI and PA. If the PI 
is outside 2000::/3 then legacy hosts will (mostly...) prefer the PA 
addresses while the multihoming aware systems can be made to prefer PI. 
Note that in this case your PI is just as reachable as PA so no need 
for two faced DNS or anything like that.

> create more complications than solve.

Ever renumber a non-tiny network?

> All end-hosts and all subnets.  Basically, everything.

So you're afraid that when to people communicate without proper 
security mechanisms in place, others might suffer? I agree that we 
shouldn't add to existing attack vectors, but I doubt that we can solve 
this general case here and now. For that, we'd need some kind of system 
that stops traffic that the destination doesn't want to receive.

> has everything to do with mobility and multi-homing.  And perhaps

Hm, I think Smurf attacks were pretty successful in singlehomed fixed 
location IPv4 networks.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Sep 2003 21:05:19 +0300

Iljitsch,

Iljitsch van Beijnum wrote:
> So you're afraid that when to people communicate without proper security 
> mechanisms in place, others might suffer? 

Exactly.  That I have been trying to say all the way along.

> I agree that we shouldn't add to existing attack vectors,

Good!

> but I doubt that we can solve this general case here and now.

I don't know what you mean with the general case.  My point has
been that if we do introduce the id/loc separation then we have to
take care of security, in order to not to add new vulnerabilities.
Perhaps I have not been able to say this clearly enough.

If you don't care about security when you do the separation, the
consequences can be severe.  We do need crypto to fix the
potential problems.  We do not necessarily need cryptographic
identifiers, but cryptographic identifiers help, and potentially
make the system much more secure.

Once more:  There is no intrinsic need to protect the actual data
traffic (even though I think it would be good in most cases),
but we do have to protect the signalling traffic that verifies
and updates the id->locs mappings in the end-hosts.  Since we have
to place the appopriate protection mechanisms there, I do not
think that we can easily allow zillions of different protocols
there, as you were suggesting.  Two or three maybe (LIN6, HIP,
MAST, counting.... :-), but more than that may have difficulties in
getting through the IESG due to the security requirements.

> Hm, I think Smurf attacks were pretty successful in singlehomed fixed 

There is a huge difference between someone getting nodes to
reflect single spoofed packets and someone legitimately
redirecting complete data streams, and only *then* starting
to spoof acoknowledgements to keep those data streams running.

I know, the MIPv6 RO security background draft is long.
But I don't have time to try to distill a shorter version
of it right now.

--Pekka Nikander

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------