Subject: Notes about identifier - locator separator

From: Pekka Nikander <[email-masked]>
Date: Sat, 02 Nov 2002 11:43:01 +0200

[During the last couple of days there have been quite a lot
  of comments, by various people, on the ideas of separating
  identifiers and locators (see the end of this message for
  some quotations).  Based on our experience on Mobile IPv6,
  the late Homeless Mobile IPv6 suggestion, and our current
  work on Mobile IPv6 security and HIP, I'd like to present
  a few observations.  Disclaimer:  I am far from being a
  routing expert, so take your usual grain of salt.]

I think that there are a number of dimensions that we
have to keep in mind when discussing separating identifiers
from locators.  Furthermore, I think that it is important
first to understand these issues and only once we really
understand the dimensions to start take positions on
specific solutions.  Maybe this is no news to you, but
writing this has certainly helped my own thinking :-)

The immediate issues that I see are the following:
   1. Architectural "structure" of the identifiers.
   2. Where to perform identifier->locator and/or locator->locator
      translations.
   3. Identifer -> locator resolution (+ reverse resolution for ops)
   4. Backwards compatibility
      a) application level backwards compatibility
      b) routing level backwards compatibility
   5. Security & Privacy issues
   6. Issuing and uniqueness of identifiers
There are most probably others, but I think these six
might work as a starting point.

1. Architectural "structure" of the identifiers

    From my point of view, there are two different basic
    approaches:

      a) make the end-point identifiers a completely
         separate name space

      b) divide the IPv6 address space into locator
         and identifier space

    Due to the chartering of this working group, I think it is
    natural that people here tend to look at solutions from the
    b) category.  However, I personally think that a completely
    separate name space might be better.  Furthermore, if we
    create a completely new name space, that would leave
    the IP address space more or less intact, allowing routing
    technogy to be developed independently of end-host mobility
    and end-host multi-homing issues.  (I do realise that network
    level mobility and multi-homing are different.  They
    probably require changes on the routing level too, and
    end-point identifiers might just act as a helping tool.)

2. Translations

    Once the end-point identifiers have been separated from
    locators, we need to translate the identifiers to locators
    at some point, and it also becomes possible to translate
    between locators.  That is, the apps will only know the
    identifiers, not locators.  Thus, at some point, the
    identifiers must be translated into locators so that the
    packets can be routed to their destination.

    Here I see two basic solutions, again:

      a) perform the identifier -> locator translation at
         the end-host so that all packets leaving the end-host
         have a proper locator,

      b) allow the identifiers to leave the end-host without
         locators, and perform the translation within the
         the network, e.g., at a site border router.

    Independent of that, it will be possible to translate
    locators to locators within the network, as long as the
    end-points are able to determine the identifiers either
    implicitly (based on state), explicitly (based on
    information carried in the packet), or bt a combination of
    state & per-packet information.

3. Resolution

    Apparently there must also be some way of finding the
    locators based on the identifier or a name.  Apparently
    there is a huge number of possible solutions to this.
    One of the most obvious ones is to store both identifiers
    and locators into the DNS, and make the name resolution
    library to fetch both.

4. Backwards compatibility

    The basic issue here is to keep the semantics of the
    fields in the application level data structures and
    the address fields in IPv6 header sufficiently intact.
    However, we must understand that the address semantics
    are different from the application point-of-view and
    from the routing point-of-view.

    a) application level backwards compatibility

    For application level compatibility, the identifiers
    must *look* like IP addresses.  That is, the current
    name resolution fuctions (getaddrinfo) must return
    something that looks enough like an address, and the
    kernel must be able to understand these.  However, if
    the identifier name space is separate from the locator
    space, and if the translation is performed at the
    end-host, these identifiers might never leave the
    end-host in the IP address fields.  Thus, it is
    possible to *separate* application level and routing
    level backwards compatibility

    b) routing level backwards compatibility

    I'm fraid I can't say much intelligent here.  You
    folks know this subject much better than I do.

5. Security and privacy

    I might as well write a separate message about this.
    (Would a draft be useful?)  However, briefly:  From
    the security point of view, there are two concerns:

     a) We want to make sure that the multi-homing
        mechanism cannot be used to "steal" addresses
        or connections.  That is, the solution must
        make sure that the end-points talking to each
        other remain the same even if the underlying
        locators are changed.

     b) We want to make sure that the multi-homing
        mechanism cannot be used as a vehicle in
        DoS attacks.  This is the "flooding" attack
        problem that I've described in other messages.

    From the privacy point of view, it would be a
    definite plus if the actual, long lasting identifiers
    would not be visible in packets.  There are
    techniques how identifiers could be cryptographically
    masked in a way that still allows middle boxes
    (such as firewalls) and end-points to still recognize
    valid identifiers but make it hard for outsiders
    to track them.  However, these naturally require
    that the identifiers are completely separated from
    locators, i.e., that they are not being used for routing.

6. Issuing and uniqueness of identifiers

    Here we once more seem to have two possibilities:

     a) The identifiers are issued hierarchically

     b) The identifiers are issued by a random number
        generator and are long enough so that the
        probability of collision is low enough.

    I know that there are doubts against b).  However,
    if the identifiers are long enough, the chance of
    collision by change can be so low that it really
    can be ignored, since a collision would be likely
    to happen less often than there are atoms in our
    universe.  (The quality of random number generators
    would still be an issue, though.)

----

Those are the dimensions as I see them.  There are
probably others.  Apparently, my personal position
is that I'd like to see that

   - identifiers are completely different from
     IP addresses, and IP addresses gradually
     become pure locators,

   - identifiers are translated into locators
     at the end-hosts, and the network performs
     locator-locator translations if needed
     e.g. for traffic engineering,

   - both identifiers and locators are stored in
     the DNS; additionally there might be dynamic
     locator->locator translation services to
     help mobility,

   - the application level and routing level
     compatibility issues are separated,

   - identifiers are cryptographic in nature so
     that it becomes easier to solve the security
     problems,

   - identifiers are usually not carried in the
     packets, just locators; this helps privacy
     and keeps the header size from growing,

   - it is *possible* to generate totally
     random identifiers; if some people want
     to use hierarchically assigned identifiers,
     I have nothing against it.

----

Some related quotations from the discussion in the
last two days.  Apologies to those occasions where
I haven't got the attribution right.

Tony Hain wrote:
> I have not been opposed to GSE, but I think the time has passed for it
> to be adopted without coupling it with something like MIPv6 to provide a
> stable identifier to the psuedo-header calculation and multi-party apps
> that insist on refering addresses rather than name strings.  

Craig A. Huegen wrote:
> With that said, let's find some solutions.  I also agree with the idea of
> separating router goop from identities; however, I also am a pragmatist
> and am concerned with the existing applications that would break with
> this.

Tony Li wrote:
 >> You are also assuming that aggregation and multihoming are somehow
 >> at odds.  They are not.  All you have to do is to disconnect
 >> the locator and the identifier as GSE does and aggregate only the
 >> locators.  Each host in a multihomed domain has a single
 >> identifier, but multiple locators.  No deaggregation happens
 >> because the locators are bound to the provider and thus we
 >> have good topological 'addressing'.  The enterprise doesn't
 >> lose because we tweak the transport to base the pseudoheader
 >> on the host identifier and then let the locator be free to be
 >> replaced by border routers.  Connections flip back and forth
 >> between locators easily.

To which Tony Hain replied:
> This model was probably possible 4 years ago, but at this point I doubt
> tweaking the pseudoheader can even be on the table. Also, 'freely
> replaced' usually sets off the alarm bells of the spoof-sensitive
> security types. That does not mean we GSE is hopeless, just that we will
> probably have to use something like MIPv6 to mask the label swapping. In
> the abstract, there is not much difference between GSE and a Care-of
> Address. So for routing & packet forwarding, if the CoA had finer
> grained pattern replacement happening the end systems would not be aware
> of it. The missing link would be letting the host know what the current
> publicly visible address is so it could pass that to the CN.

In a later message, Tony Hain wrote:
> But since there is no way to ensure that an identifier is globally
> unique, the only way to accomplish the goal is to couple them to
> describe 'this identifier at this location'. If the location is not
> stable, the static description is not stable. 
...
> Because the identifier is not stable & globally unique, and even if we
> had a way to ensure that, the privacy advocate's alarms would be going
> off. Despite the desire to avoid it, the current reality is that to
> create a globally unique identifier we bound the problem by coupling it
> with its locator.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 2 Nov 2002 14:34:41 +0100 (CET)

>     and end-host multi-homing issues.

As it seems to be open season on all aspects of the TCP/IP architecture,
let's follow this reasoning to its logical conclusion and make the
identifier the full host name.

Let's go with this for a moment. Now obviously IP will be unable to
route based on hostnames, so the whole thing must be done at the
transport layer. Retrofitting TCP is probably not worth it, so we make a
new transport protocol. As I've said before, doing multihoming at the
transport layer has many drawbacks compatibility-wise, but if we're
going to do some major architectural work, we may as well go the full
nine yards and solve everything once and for all.

Since the identifiers aren't carried in IP and we need extra locators,
there must be some serious session establishment. Doing this in UDP
defeats the purpose. So apps that use straight UDP must either live with
the fact that they are not multihomed (which may be ok for something
like syslog) or implement their own multihoming mechanisms (such as the
DNS already does). However, many applications don't use UDP as-is but
use a UDP-based real-time transport protocol. As long as we're building
a new transport protocol, we may as well address this need too and
implement an unreliable and possibly as semi-reliable (for multicast?)
mode in addition to the regular TCP-like reliable mode.

A nice addition would be having a better checksum for the new protocol.
If we replace the TCP checksum by an MD5 hash or part thereof that is
calculated over the packet contents, assorted transport layer fields
such as the sequence number, the identifier and some kind of magic
cookie, it becomes pretty hard for someone to steal a session without
having seen the intial identifier/cookie exchange. Obviously more
extensive mechanisms can be negotiated as well if desired.

Since we now have all the functionality we'll ever need in our new
transportzilla protocol, there is no need to change IP or routing.

Also, the network layer is now completely hidden from the application.
So moving from IPv4 to IPv6 to IPv6 multihomed to IPv7 and IPv9
(skipping IPv8) will be a breeze.

Most application builders will love this since they can finally stop
worrying about resolving domain names in their applications. (Although
the fact that they have to change their apps in itself may not be
greeted with much enthusiasm for those who already did the v6 work, but
most are still v4-only anyway.)

>      e.g. for traffic engineering,

A good way to do traffic engineering if the hosts are in charge of the
identifier->locator substitution would be a way to add preference
information to each locator. To be crude: the DNS looks in the BGP
table to see which locators are better connected and includes this
information in the replies.

BTW, in order to do this right (traffic engineering incoming traffic) we
also need to make the host ask for advice on which source address it
should use.

Iljitsch

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 02 Nov 2002 23:30:02 +0200

> identifier the full host name.

I like this approach, but I don't agree with your conclusions.
Let's see why.

> transport layer. 

Already here you make a statement that I don't sign.  As of today,
IP has also other functions but routing.  Routing is the main
function of IP from the router point of view, true.  But from a
host or application point of view, IP *also* provides a name space
for end-points.

If you separate locators completely from end-point identifiers,
the logical conclusion is NOT to move the function to the
transport layer but to split the IP layer into two halves:

-  A "lower" IP that routers packets much as today, and uses
    IP addresses as locators.

-  An "upper" IP that provides end-point identifiers to the
    transport protocols and eventually to the hosted applications,
    and maps these identifiers to locators before passing them
    to the "lower" IP.

Or that's at least I see HIP.  :-)   If you want to, you can
give the "upper" IP some other name, like "Host Layer" or
"Common Lower Transport Layer" or whatever.  The point is that
it is completely underneath current transport protocols.
(And optional, as I discuss below.)

> Retrofitting TCP is probably not worth it, so we make a

If we take the position that multi-homing needs to be implemented
at the transport layer, I by and large agree with you.  And we
already have SCTP.  One possible way that I see is to implement
compatibility "shims" so that you can run legacy TCP and UDP
applications over SCTP.  (I think Brian mentioned this a while
back.)

However, based on my limited understanding, I think that splitting
IP into two sub-layers would *probably* be better.  The reasons
are related to security, signalling overhead, and architectural
"beaty".  I definitely don't mean that a solution based on SCTP
would not work or be viable.  I just want to say that I do find
the idea of separate end-point identifiers and a separate layer
for them better.

> there must be some serious session establishment.

Agreed.  There are also security issues involved, requiring
session establishment.  However, some of these security issues
would be present even if the locators and identifiers are
separated "within" the IP address space á la 8+8.

> Doing this in UDP
> DNS already does).

If we split the IP layer into two sub-layers, I think that it should
still be possible to use TCP/UDP either with the additional
services provided by the "end-host identifier" layer or without it.
When used without, the "new" services like multi-homing would not
be available.  However, this would be perfectly fine for short term
request-response services.

Architectural flexibility seems like a key issue here.

[Some comments clipped since I didnt' find them relevant,
  even though they certainly were amusing :-) ]

> information in the replies.

Would you please clarify?  I didn't quite understand.

> also need to make the host ask for advice on which source address it

Well, if you separate identifiers from locators, the semantics of
the source address also change, at least potentially.  We wrote
a tongue-in-the-cheek paper about that to a local security conference
(Nordsec) last year.  It was titled "IPv6 source addresses considered
harmful."  For a couple of chuckles, see

http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

BTW, my co-auther presented it and according to her most of the
audience didn't get it while a couple had difficulties in keeping
on their chairs and not rolling on the ground.  :-) :-)

--Pekka

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2002 16:58:07 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    Pekka> 1. Architectural "structure" of the identifiers

    Pekka>     From my point of view, there are two different basic
    Pekka>     approaches:

    Pekka>       a) make the end-point identifiers a completely
    Pekka>          separate name space

  To me, this is trivially done by either extension headers, or layers
of IP/IP. The later has the advantage that it naturally fits into IPsec.

    Pekka> 2. Translations

    Pekka>     Here I see two basic solutions, again:

    Pekka>       a) perform the identifier -> locator translation at
    Pekka>          the end-host so that all packets leaving the end-host
    Pekka>          have a proper locator,

    Pekka>       b) allow the identifiers to leave the end-host without
    Pekka>          locators, and perform the translation within the
    Pekka>          the network, e.g., at a site border router.

  IPsec-type processing permits either. This is just gateway vs host.
We also can do bump-in-the-stack/wire, but I hope we won't.

    Pekka> 4. Backwards compatibility

  This is equivalent to saying that one will permit cleartext traffic
to single-homed boxes whose locator = end-point identifier.  

    Pekka> 5. Security and privacy

  We have solutions to this problem.

    Pekka>     From the privacy point of view, it would be a
    Pekka>     definite plus if the actual, long lasting identifiers
    Pekka>     would not be visible in packets.  There are

  It would even better if the whole data contents were private.
  If the "cost" of being multihomed is that you have to strongly authenticate
and/or encrypt your data... well... I'll be pushing everyone to become multihomed!

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2002 17:04:08 -0500

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    Pekka> If we take the position that multi-homing needs to be implemented
    Pekka> at the transport layer, I by and large agree with you.  And we
    Pekka> already have SCTP.  One possible way that I see is to implement
    Pekka> compatibility "shims" so that you can run legacy TCP and UDP
    Pekka> applications over SCTP.  (I think Brian mentioned this a while
    Pekka> back.)

  My understanding from talking to Randall is that the SCTP API already
permits three ways to interact with SCTP:
	- a SOCK_DGRAM (aka UDP) compatible way
	- a SOCK_STREAM (aka TCP) compatible way
	- and an SCTP specific way that gives you visibility into 
	the ordered and unordered pieces, and the multiple addresses.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 2 Nov 2002 23:23:23 +0100 (CET)

> I like this approach, but I don't agree with your conclusions.

Ok...

> host or application point of view, IP *also* provides a name space

I don't understand.

>     and maps these identifiers to locators before passing them

Ok, that makes some sense. I believe the IEEE slices a single OSI layer
at least three ways so two is modest.

However, what will the interaction with the upper layer be like? Either
this has to be done using the new identifiers, which isn't good. I'm not
completely sure how much of the inefficiencies of string handling (as
compared to working with a fixed length machine word size aligned value)
modern processors can optimize away, but I doubt it's the entire thing.
This would get pretty bad in machines with very many sessions.
Alternatively, there must be some kind of state. That's contrary to the
IP (as in IP layer, not TCP/IP as a whole) philosophy.

> at the transport layer, I by and large agree with you.

A reason to not want this is that it requires big changes to existing
code. But many of the things we've been discussing lately do this
anyway. Apart from that my main gripe with doing it at the transport
layer is that we can't offload the processing to a box external to the
end host. On the other hand the big plus is that the tranport layer
knows when to switch locators.

> And we already have SCTP.

I'm not fully familiar with SCTP, but it's never intended to fully solve
the multihoming problem, and I'm not convinced it is as advanced as TCP
with regard to congestion issues. (Although I believe we can improve on
TCP in that regard, but at least its track record is proven and
well-known.)

> One possible way that I see is to implement

You mean intercept the old APIs and translate them to new stuff. I guess
this could work. Still, IPv6 deployment isn't that huge so if we can
make something that is really very good, people will want it and we
shouldn't have to deal with much legacy stuff.

About UDP: this is intended to be a light weight protocol. Running it on
top of a heavy weight protocol defeats the purpose. Also, you'll get
into trouble if you end up doing name server request over the multihomed
transport as this new transport needs to go to the DNS itself.

> IP into two sub-layers would *probably* be better.

Tell us more about how this works and what it solves.

> Would you please clarify?  I didn't quite understand.

You open a connection to blah.com. The new transport protocol looks up
the locators associated with blah.com. Suppose they are abc::1 and
def::1. Today, the DNS/resolver library either presents the addresses to
the application in the order they were received or orders them
semi-randomly (round robin) to achieve some load balancing. The DNS
and/or resolver could look in the routing tables and sort the addresses
according to their routing metric (suppose abc::/32 is 3 AS hops away
and def::/32 1 AS hop, def::1 would be first and abc::1 second) but it
would be better to list an explicit preference value (for instance,
abc::1 pref = 33, def::1 pref = 100).

> http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

I didn't read the whole thing but it seemed at least somewhat serious...
Leaving out source addresses means you can't protect yourself against
DoS attacks.

Iljitsch

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Nov 2002 09:23:38 +0859 ()

Pekka;

>   routing expert, so take your usual grain of salt.]

You are mostly correct.

However, you made mistakes on security, DNS and mobility.

>     would not be visible in packets.

Your privacy concern is caused by long lasting IDs by itself and
has nothing to do with visibility in packets. No one think it a
problem that their phone numbers are visible in SS7 packets.

Long lasting IDs weaken privacy because it is used as a key to
merge multiple databases.

>     There are
>     to track them.

As long as the end-points, which hold the databases, can
recognize the ID, the end-points can merge their databases.

You might think that, the concern can be avoided with short-lived
ID. However, long lasting database entries needs long lasting IDs.

The solution is to accept the reality.

Those who mind can change their IDs as frequently as they want
or can use multiple IDs at once.

>     and locators into the DNS, and make the name resolution

You seems to be thinking of inverse query, leagacy feature found in
RFC103[45] replaced by in-addr.arpa. However, it does not work.

If you rely on DNS, you must make DNS work in multihomed environment.

In addition, you can't force DNS act quickly enough for mobility.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 03 Nov 2002 09:24:07 +0200

Ohta-san,

> However, you made mistakes on security, DNS and mobility.

I am always eager to learn more.  Thank you for providing
this opportunity.

> merge multiple databases.

Well, let me both agree and disagree with you.  From my point
of view, the situation is not as simple as you seem to say.
But maybe we are just talking about the same thing with
different words.

Firstly, if we want to build long lasting relationships, we
need long lasting identifiers.  There we seem to agree.

However, the long lasting identifiers are no business to
those outside of that relationship.   The relationship may
be binary, in which case the IDs are relevant only to the
two communicating parties.  Or it may have higher arity,
in which case there are also other parties that have
legitimite access to the identifiers.

Secondly, given a single packet travelling in the network,
the long lasting IDs may be presented in clear text, or
alternatively they may be either implied or encrypted.
If they are not present in clear text, most parties
that see the packet have no access to the IDs.  On the other
hand, the receiver of the packet, and perhaps also some
middle boxes (such as a corporate firewall) do need to have
access to the IDs.

The key here is state.  If the middle box or the receiver
has state (e.g. a cryptographic key or a communication context),
it can check that the arriving packet indeed contains or
implies a known long lasting identifier, and act accordingly.
However, parties that do not have that state cannot find
out the long lasting identifiers.

If we want to go to the heavy transactions track, Marianne
Winslett in one hand and the KeyNote guys (Bellovin, Blaze,
Feigenbaum, Keromytis, JI, and more recently also others)
have done quite a lot of work.  However, if we want to hide
the long lasting IDs but not pay the cost of PK crypto, there
seems to be fewer published works.

> ID. However, long lasting database entries needs long lasting IDs.

The issue with database merging is completely different.
That can be resolved by having multiple pseudonyms that
cannot be easily linked.  However, each of the pseudonyms
can be long lasting by itself.

> The solution is to accept the reality.

Of course.  I couldn't agree more.  And IMHO, the reality
also includes parties that attempt to perform traffic
analysis on the packets flowing in the wire instead of
trying to penetrate to the end-points.  Echelon comes
to my mind...

-----

> RFC103[45] replaced by in-addr.arpa. However, it does not work.

Would you please point me to text that explains why the
reverse DNS database does not work, and in which way?

OTOH, I was mostly thinking about a very simple forward
resolution:

   a.domain.name -> (identifier, locator, locator)

For example,

   a.domain.name.   IN   AAAA  locator1
                    IN   AAAA  locator2
                    IN   XXX   identifier

where XXX would be either a new RR type or, e.g., KEY RR,
if public keys were used as identifiers.

What comes to identifier -> locator resolution, I don't
think there is anything ready.  Distributed Hash Tables
seem like one possible future technology, but it has
a long way to go before it can become a part of the
established infrastructure, if ever.

Or alternatively the identifiers could be hierarchically
assigned.

> If you rely on DNS, you must make DNS work in multihomed environment.

I agree, and I'd like to learn better the issues around this.

> In addition, you can't force DNS act quickly enough for mobility.

Yes, I know.  For mobility something like Home Agents or LIN6
identifiers are needed.  In the HIP architecture, this is
called randezvous service.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 03 Nov 2002 12:58:53 +0200

> I don't understand.

Hmm.  I'm not quite sure what you don't understand.  :-)

Obviously, the text book explanation of IP is that IP
provides the packet forwarding service, and needs routing
in order to be able to forward packets.  But as we all
know, there is more in IP.

 From my point of view, end-point naming is one of the most
important "services" IP provides today (in addition to
the packet forwarding "service", of course).  That is,
the TCP and UDP port numbers are qualified by the IP
address of the host currently hosting the application.
In order words, IP provides a name space for end-points,
and the application level entities (sockets) are named
by concatenating the IP address and the port number
(and in some other cases, like TCP MUX and ONC RPC, also
other information).

But this should all be trivial; I am unsure why we are
discussing this.

Well, maybe the reason lies in the fact that the
sublayering idea takes explicit advantage of that
the packet forwarding "service" and end-point naming
"service" need not be so tightly bound as they are today.

...
 > This would get pretty bad in machines with very many sessions.

There are two issues here:  The "real" nature of the new identifiers,
and the representation of the new identifiers in application data
structures.  For application level backwards compatibility, we
obviously want the new identifiers to look (almost) like IP addresses.
If they do, they can be stored in existing data structures, and
we can provide binary compatibility to (almost) all existing
applications.  (The only exception are applications that explicitly
inspect the IP addresses to determine their properties.) No need
for string handling at all.

Thus, as long as application level backwards compatibility is an issue,
we want the interaction between the "upper" IP layer and the transport
layer to look like it looks like today.  The syntax would be (almost)
the same, just the semantics different.  The essence of the semantic
difference would be the hiding of the underlying changing IP addresses.
Today most programs today do not expect the IP addresses to change,
but they do expect the socket to remain connected to the same peer host.
Thus, in a way, the semantic change is not much of a change for most
of the applications.  Most applications are primarily interested on
the peer hosts anyway, not their IP addresses.

The real nature of the end-point identifiers is then a completely
different story.  Either they can be something that fits into
128 bits, or they can be something that does not.  If they do not,
the 128 bits stored in the application data structures would be
a "pointer" to the actual end-point identifier.  In the HIP
case the 128 bit representation is a hash of a public key, while
the actual end-point identifier is the public key.

> IP (as in IP layer, not TCP/IP as a whole) philosophy.

Well, there is certainly state at the IP layer.  The real question
is where and what kind of state.  For example, if you look at the
*BSD TCP/IP implementation, there is certainly state at the IP
layer.  It is represented in the form of routing table entries.
And part of this state is not related to routing at all, but is
essentially end-to-end information, such as PMTU and RTT estimates.

> Tell us more about how this works and what it solves.

Well, it is hard to tell in detail how it would work, unless
we have some very concrete proposal at hand.  And if we go
into the details of a specific proposal, they will be lenghty.
As examples, both HIP and LIN6 have been documented fairly
well, I think.

Well, what does it solve then?  Apparently it helps to
separate the identifiers from locators, thereby solving
end-host mobility and multi-homing, and perhaps helping
with NEMO style mobile networks and site multi-homing.

> Leaving out source addresses means you can't protect yourself against

Source addresses don't help much with DDoS attacks today.
I sincerely doubt they ever would.  I think that the idea
that ingress filtering would effectively cut down DDoS
is a fallacy.  But some others disagree with me, I know.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 Nov 2002 13:29:27 +0100 (CET)

On Sun, 3 Nov 2002, Pekka Nikander wrote:

> the packet forwarding "service", of course).

Ah, I see.

> obviously want the new identifiers to look (almost) like IP addresses.

We should have a new API that makes it possible to use the real
identifiers (= the host names). Obviously you can map a 32 or 128 bit
value to a name and put this name in the DNS so you can run old
applications over the new transport protocol. However, that means you
have to sacrifice the old API(s) as you either use them as they are now
(= no old programs use the new transport) or reroute them over the new
transport (= no programs can use regular IPv4 or IPv6). For IPv6 this
would be bad. For IPv4 it would be good if the host doesn't have an IPv4
address. It can then connect to dual-stack IPv6 hosts over IPv6 with the
application thinking it's doing IPv4. This would break some stuff if the
originating host doesn't have a valid IPv4 address, though.

> layer to look like it looks like today.

No, we want a new API so new apps can be clean. Use dirty hacks for the
old stuff if we need backward compatibility.

> is a fallacy.  But some others disagree with me, I know.

One of them being me. Besides, nobody can predict the future: "640k
should be enough for everyone." "There is only a market for five
computers world wide: one for each continent." "George Lucas is insane.
Who is ever going to download an entire movie over the net?"

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Nov 2002 21:48:07 +0859 ()

Pekka;

> (and in some other cases, like TCP MUX and ONC RPC, also

That is a transport layer centric view and is wrong.

At the transport layer, which is purely within a host, there is no
routing that locator aspect of IPv4 addresses is not visible.

However, the most important property of the Internet is global
connectivity between hosts that the most important service
of IP is the global connectivity.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Nov 2002 22:25:59 +0859 ()

Pekka;

> But maybe we are just talking about the same thing with

Unfortunately, no.

> middle boxes (such as a corporate firewall) do need to have

It has nothing to do with whether the ID is long lasting or not.

Note also that locaters often act as long lasting IDs.

> out the long lasting identifiers.

For a receiver to retrieve an appropriate cryptographic key or
a communication context for a packet, a long lasting ID in clear
text, as an index to the long lasting database of key or context,
must be carried by the packet.

Once such key or context is retrieved, the following packets of a
connection can use locators as a short lasting IDs. But, it does not
mean that a long lasting ID is not initially necessary.

> seems to be fewer published works.

PK is useless.

Crypto works only if you tell your ID, that is, some index information
to retrive a cryptographic key or a communication context, in clear
text, to the other end.

> trying to penetrate to the end-points.  Echelon comes

Proxies are a way aginst Echelon.

However, more important aspect of the reality is that if identity
of someone is hidden, the network is valunerable to SPAM and other
forms of DOS.

In your case, as locators act as a long lasting ID, Echelon works
fine and SPAMMers can be traced.

Cyber terrorists can still use chains of a lot of proxies to make
the trace more difficult and the Internet less secure.

But that is unavoidable reality.

> reverse DNS database does not work, and in which way?

I said "inverse query". See the RFCs.

> I agree, and I'd like to learn better the issues around this.

There are complex issues. The first step of learning is to read basic
RFCs.

> called randezvous service.

I feel some difficulty that you call such approach "Homeless".

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 03 Nov 2002 19:09:05 +0200

Ohta-san,

[Changed the subject to better match the contents.  Furthermore,
  this starts to be off-topic.]

> must be carried by the packet.

Not necessarily.  Since you don't seem to believe in PK and
apparently also not in zero knowledge protocols, let me give
a simple example with only hash functions.

Let us assume that Alice's long lasting ID is A, and she
is contacting Bob.  Let the ID space be sparse, i.e., so
that there are few IDs compared to the whole space.  For
the example to make sense in the first place, Alice and Bob
must have talked to each other beforehand, and Bob therefore
knows A.

Now, instead of sending A, Alice generates a random nonce N,
and sends

    <N>, <hash(N | A)>, and perhaps <first(k, A)>

where first(k, A) are the first k bits of A.  Note that this
message does not carry A, it only carries values derived
from A.

Bob can now retrieve from his database all IDs whose first
k bits match with <first(k, A), and try them out one after
another.  Once he finds an ID where

   hash(N | ID) == <hash(N | A)>

he knows that he has found the right ID.  Unless an attacker
possesses exactly the same database as Bob, it has much
larger task ahead and in many cases can't be sure about
Alice's identifier A even after the search.

Thus, with some computational cost at the context setup
you can hide the long term identifiers from outsiders.
(To be secure against DoS, the context setup must be
protected against resource exhausting DoS but that can
be easily done with a cookie exchange.)  After the context
has been set up, it can be indexed with a short term
connection ID, as you seem to agree.

> mean that a long lasting ID is not initially necessary.

I think I have countered your claim.  There are more complex,
and more effective, crypto protocols where you can get even
better results.  (Sorry, I can't give references out of hand,
but I can dig up if you are interested.)

> Proxies are a way aginst Echelon.

Proxies mean inefficient routing.

> of someone is hidden, the network is valunerable to SPAM and other

If the ID is hidden from the network, that doesn't necessarily
make the network vulnerable to SPAM or DoS.  Firstly, only a
recipient is vulnerable to SPAM, not a network.  An effective
way against SPAM is to impose an artificial computational cost
on the sender of a message.  An effective way against certain
types of DoS is to impose an artificial computational cost
on the initiator of a session.  If you don't believe me, here I
have a number of references ready, if you are interested.

You can design a network for privacy, still have it open, and
make it DoS resistant.  To do so, you have to understand the
economics of security.  See e.g. Ross Andersson's paper on
last year's ACSAC for a fairly good introduction.

If you are concerned about terrorism and privacy at the same time,
you can design protocols that allow pseudonomity but where the
pseudonomity can be broken at a computational cost.  That allows
NSA with its vast CPU farms to break privacy, but not the (a)typical
spying ISP.  That is, if you want such a system, you can develop
such a system.

What comes to me, I don't want my children to ever live in "1984".

There is no black and white in security or privacy, even though
some security or privacy zealots seem to think in that way.
Security engineering is engineering, with conflicting goals,
just like any engineering.  You don't gain much by throwing
away the amount of security and privacy that you can reasonably
design in.

--------

> I said "inverse query". See the RFCs.

My apologies for misreading your sentence.  It's been a while
since I last read through the DNS RFCs, and I had forgotten
the existense of inverse query.  Apparently I seem to forget
things that don't work.

--------

> I feel some difficulty that you call such approach "Homeless".

If you haven't noticed, I abandoned the "Homeless" MIPv6 idea
almost two years ago, just a few months after the ID was out.
Besides, the name was just a catchy phrase, meant to point out
how the MIPv6 home agent is becoming an unnecessary single point
of failure.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 4 Nov 2002 10:39:30 +0859 ()

Pekka;

> Now, instead of sending A, Alice generates a random nonce N,

And sends just N, as an ID.

It is called a cookie.

But, your case is even simpler.

> k bits match with <first(k, A),

With your assumption that Bob has A even before they first
communicate, everything is possible.

The hidden assumption is that Alice and Bob has a secure OOB
channel before the beginning or that A is publicly known to
everyone.

Note that, if A is known by a sniffer, locators of A is publicly
available, which is required for multihoming, that frequent
changes of locators is not a protection against traffic analysis.

> Proxies mean inefficient routing.

As you understand, it is a routing issue that locators act as
IDs.

> on the initiator of a session.

That is pointless.

That I can make some form of DoS difficult does not mean I can
identify the attacker nor can I be protected from other forms
of DoS.

> If you don't believe me, here I

I know an effective way against SPAM with current SMTP as is is
not to give any reply for SYN.

> last year's ACSAC for a fairly good introduction.

First, you should understand the real networking, including, but
not limited to economics.

Say, for example, cookie.

> spying ISP.  That is, if you want such a system, you can develop

Do you know how the computational cost varies?

> What comes to me, I don't want my children to ever live in "1984".

That is the problem.

In good old days of 1984, DES was unbreakable.

In 2001, though we still don't have HAL...

> away the amount of security and privacy that you can reasonably

How can you say engineering?

> the existense of inverse query.  Apparently I seem to forget

Remembering a mistake is good not to repeat the mistake.

...

Good terminology is the first step toward good engineering.

> how the MIPv6 home agent is becoming an unnecessary single point

It is trivially easy to make an RFC 2002 compliant mobilie host
have multiple home agents. A mobile host should just send
multiple registration packets.

I even proposed so to mobile WG people and told it too late to be
added, long after which, RFC 2002 was published. :-)

						Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 04 Nov 2002 08:16:52 +0200

I am taking this off-line since I don't believe this
any more belongs to multi6.

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 14:46:15 -0500

On Saturday, Nov 2, 2002, at 08:34 America/Montreal, Iljitsch van 
> identifier the full host name.

It is important to understand that FQDNs are *not* globally unique
in identifying a single host.

This isn't an objection to your proposal, just an observation that
you're proposing that we continue to use identifiers that are not
globally unique.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 14:55:05 -0500

> must be carried by the packet.

SPIs in ESP/AH are examples of IDs contained in a packet used
as an index to the Security Association state.  SPIs are not
normally long-lasting -- typically only valid for the lifetime
of the SA (plus epsilon).  Any sane key management strategy
involves changing *session* keys *at least* every 24 hours,
even for very strong cryptographic algorithms.

So the claim above is bogus (or poorly written).

Ran

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 04 Nov 2002 22:25:41 +0200

Ran,

>> Pekka Nikander wrote:

> even for very strong cryptographic algorithms.

With all respect, I think that the situation is slightly
more subtle.  Let me make a usual Alice and Bob style
example.

  1. If Alice and Bob have never communicated before
     (and don't have a mutual reference point), the
     ID Alice sends to Bob does not carry any information.

     Summary: a fresh ID carries no information.

     Thus, Alice can choose the ID freely, with the
     assumption that Bob will associate some state
     with the ID.  OTOH, the ID must somehow be communicated,
     and it will be vulnerable to discosure, even if
     unauthenticated D-H is used.

  2. If Alice and Bob have communicated before, Alice
     has to send the same ID to Bob so that he can retrive
     the afore mentioned state.  For privacy reasons she
     does not want to send it in clear text.  If she has
     recorded Bob's PK the issue is trivial, of course, but
     let's pretend for a while that PK crypto does not exist
     (Ohta-san does not believe in PK.)

     Now, if Bob knows Alice only by this long lasting ID and
     does not have any short term state with Alice, Alice
     basically MUST communicate the ID to Bob so that Bob can
     retrieve the state.  As far as I understand, that is
     what Ohta-san says.

     OTOH, he is obviously wrong in stating that the ID must
     be send in clear text, even in the absense of PK crypto.
     There are other means, as you well know.

     Summary: An ID must be communicated if one wants to
     refer to it, but it does not need to be communicated
     in clear.

--Pekka

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 01:35:51 +0100 (CET)

> in identifying a single host.

This could be considered a feature and not a bug.  :-)

It is of course trivial to make these unique if desired.

> you're proposing that we continue to use identifiers that are not

It depends on what we want to address. I think most applications are
interested in talking to a specific service rather than a specific host.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 10:57:53 +0100 (CET)

> This could be considered a feature and not a bug.  :-)

Hm, let's think about this.

A host wants to connect to a specific service tied to a host name. Our
new transport protocol looks up the host name in the DNS or a new
identifier->locator mapping mechanism and starts to establish a session
with one of the locators. Obviously, this locator could belong to the
target host and that's the end of it.

On the other hand, the locator could belong to some intermediate box.
This could be a box that is responsible for server load balancing or
traffic engineering, or it could be a mobility home agent (one of
several). The intermediate box would then negotiate replacement locators
and after that the rest of the session establishment procedure can be
executed.

This provides a very clean solution to the server load balancing and
traffic engineering problems, as the box handling this only has to see
session establishment packets and not _all_ traffic. I'm not sure if
this type of mobility is better than other proposals, but it would be
fairly trivial to implement it.

The more I think about it, the more I like this transportzilla solution.
The only down side is now I have to learn everything there is to know
about transport issues just when I thought I was getting a handle on
this routing stuff.  :-(

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 17:35:08 +0100 (CET)

> On Tue, 5 Nov 2002, Iljitsch van Beijnum wrote:

I must say I like this replying to myself thing! Much less confusion.

> and after that the rest of the session establishment procedure can be

Originally, I thought backward compatibility with TCP would be
problematic. However, I think it can be done in a way that isn't (too)
harmful, and backward compatibility is of course a very useful thing to
have.

The basic idea is that session establishment needs a lot of extra stuff.
However, the actual data transfer doesn't have to look different from
TCP. It can even be compatible with TCP if suitable 4 or 16 byte
identifiers are used rather than the real one (the host name). So if a
transportzilla-implementation wants to talk to a regular IPv6 or IPv4
TCP implementation, the only thing that's needed is a box or wedge that
handles the locator and options negotation. One of the options that are
negotiated would then be IPv6 or IPv4 compatible session identifiers. If
both hosts are in the possesion of the right type of address, this will
obviously used, but if they aren't, anything that looks like such an
address can be used as long as there are no clashes with other sessions.
(For instance, host A could assign host B an address from 10.0.0.0/8 and
host B host A another one.

When the session is established, the extra box or wedge simply swaps
around the identifiers/locators and the TCP protocol number vs the
transportzilla one and the old TCP implementation will never know the
difference. The packet format (including the way the checksum is
calculated) would have to match regular TCP. This also makes
implementing transportzilla extremely easy as all the hard stuff such as
congestion control can simply be reused from TCP.

When running transportzilla over the old IPv4/IPv6 APIs it makes no
sense to do all of the above. Rather, the IPv6 or IPv4 address is turned
into a hostname (could be in-addr.arpa or ip6.int or something else) and
this address is used as the TCPv6/v4 compatible identifier.

I'll have to do some more brooding about how to work UDP based stuff
into all of this but the idea should be pretty much like TCP: have a new
session establishment paradigm but keep actual data packets the same if
possible.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 06:54:03 +0859 ()

Ran;

> even for very strong cryptographic algorithms.

We are talking about host identity.

ESP/AH use IP addresses, which identify  hosts, and SPIs.

						Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Nov 2002 22:51:39 +0100 (CET)

Useful writeup. Some comments.

>          the end-host so that all packets leaving the end-host

Is the singular "a proper locator" intentional or a mistake?
I think each packet need both a source locator and a destination locator
in order to enable ICMP errors and e.g. TCP SYN+ACK messages to be returned
without anybody having to perform a mapping - since doing such a mapping
in response to a single packet would be a field day for DoS attacks.

>          the network, e.g., at a site border router.

But on a larger issue, it isn't clear to me that a translation is necessary
(except for debugging) if one would always carry around blobs that consist
of the indentifier plus a set of (possibly stale or not working) locators.
It would be useful to understand the different impact on the applications
for such a case. For instance, if porting applications to IPv6 means that
they use getaddrinfo hence can handle variable length "address" structures
without any additional changes...

If the translation needs to be present in the performance and DoS critical
path I think it would be quite critical to understand how such
a translation function can be constructed.

>     and locators into the DNS, and make the name resolution

That doesn't work e.g. for the passive side of a TCP conenction where
the transport protocol, and often not even the application, do a DNS lookup.
Unless you carry a source identifier plus a list of source locators in
e.g. the TCP SYN packet.

>     a) application level backwards compatibility

In addition to the constraint you list, presumaby we do not want to require 
that multi-party applications change significantly. Thus an application should
be able to take the address it got from getaddrinfo(), the local pr remote 
address of some existing connection (getsockname() and getpeername() type
stuff) and pass that address to another peer in the multi-party application.
Thus if you only expose the identifier to the application in these calls,
then you must be able to perform the identifier->locator mapping
in other hosts that have not done a DNS lookup of the hostname.

> probably others. 

One additional issue on my list is to what extent one can ease deployment of
a new scheme by being able to derive some benefits when e.g. the local host
and the local border routers implement the new stuff, but the peer host
and peer border routers do not.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Nov 2002 22:51:39 +0100 (CET)

Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Nov 2002 14:31:28 +0100 (CET)

> Is the singular "a proper locator" intentional or a mistake?

:-)  I think that would be one for source, one for destination. (As
opposed to more than one for each.)

> without any additional changes...

The idea is that an external box could handle this so a non-multihoming
aware host can enjoy being multihomed. And are you suggesting we should
carry all addresses in all packets? That would be a huge waste of
bandwidth. Not something IPv6 really needs as it is borderline in this
area as it is.

(There are also solutions where both the host and the border
routers/external boxes must be changed, though.)

> Unless you carry a source identifier plus a list of source locators in

That would be a necessary part of any solution that uses the "forward"
DNS functionality. You could also look up information for the remote
address that is seen in the incoming session, but that is a more
dangerous use of the DNS.

It is also possible to use some new way to map identifiers to locators
and not the DNS.

> and peer border routers do not.

That means the routers have to solve the problem, as is done today. This
works very well but there are scalability issues. Have a look at:

1. http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt
2. http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
3. http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt

1. proposes a new aggregation mechanism that makes current multihoming
mechanisms a lot more scalable, but probably not enough. 2. is an
aliasing (address replacement) solution that has the necessary
scalability. They both use the address allocation plan 3., so it is
possible to make the transition from 1. to 2. relatively painlessly.
That way, there is more than enough time for current border routers to
implement the new mechanisms.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 8 Nov 2002 16:00:09 +0100 (CET)

> bandwidth. Not something IPv6 really needs as it is borderline in this

I'm not suggesting anything - I'm merely trying to promote getting a shared
understanding that includes applications, DNS, transports, hosts, routers,
enterprises, ISPs, and the DFZ. 

I haven't seen much discussion (but I'm still horribly behind on mail)
about what the issues are around applications as it relates to multihomed
sites.

> routers/external boxes must be changed, though.)

And there are probably also solutions where every multi(>2)-party application
must be modified.

> It is also possible to use some new way to map identifiers to locators

But that doesn't change the fundamental danger of having a single
packet (whether it is a TCP SYN or a packet that needs be get an ICMP
error sent back) resulting in significant work such as doing a lookup
in some mapping service.

> > One additional issue on my list is to what extent one can ease deployment
> of > a new scheme by being able to derive some benefits when e.g. the local
> host > and the local border routers implement the new stuff, but the peer
> host > and peer border routers do not.
> 

That doesn't follow AFAIK.

Combinations of host and border router functionality might very well be
able to provide partial benefits without requiring changes at the other end.
At least I see no fundamental reason why such combinations can not add
something interesting to the solution space.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 08 Nov 2002 22:34:08 +0200

> in response to a single packet would be a field day for DoS attacks.

Well, I think the singular form was primarily a mistake, but it could
have been intentional.  If we go to the separated ID/locator world,
the semantics of the source address change more than the semantics
of the destination address.  The source address could either function
as the return address, as you describe, or it could be used by the
network to record the return route for traceback purposes, or it could
be both.  However, combining both functions into a single field has
a two edged result: in one hand it prevents reflection for DoS purpose,
in the other hand it makes it hard to ask replies to be sent to a
topologically different location, e.g., due to asymmetric routing
or traffic conditions.

I guess I already mentioned our half tongue-in-the-cheek NordSec paper
considering some of the aspects: "IPv6 Source Addresses Considered Harmful"
http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

I have never thought that the source address field would carry a source
identifier.  From my point of view, such an arrangement would be
silly: you couldn't use the ID for routing, and you couldn't use
it for reliably identifying the source either, since anybody could
lie in the first packet they send.

> Unless you carry a source identifier plus a list of source locators in

This has been discussed to an extend in the other messages, but one
additional comment:  It is sometimes enough to carry a single source
locator in the TCP SYN packet; the rest can be sent later.

What comes to the applications that use getpeername etc and send
the address in the protocol, personally I don't care too much
about the (apparently rare) cases where something gets broken.
In most cases the recipient will know the identifier already,
and is able to do the mapping.

On the other hand, ...

> in other hosts that have not done a DNS lookup of the hostname.

... I do imagine that something like Distributed Hash Tables (DHT)
could be used to implement identifier->locator mapping, if really
needed.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Nov 2002 17:26:36 +0100 (CET)

> and is able to do the mapping.

This depends on whether there are datagram'ish functions which need the
indentifier. For instance, if ESP/AH want to operate with SAs bound to 
the identifiers then it seems like the TCP SYN needs both a source
identifier (for ESP/AH) and a source locator (so that TCP can respond
without having to do the mapping from identifier to locator on the 1st packet).
> could be used to implement identifier->locator mapping, if really

Do you have a reference?

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Nov 2002 21:02:51 +0200

Erik Nordmark wrote:
> identifier.  

Right.  The way we do HIP today is that we allow bypassing it.
It is actually better to bypass HIP if you are doing a DNS query,
trying to synchronize clocks with NTP, or something else like that.

In our vision, HIP (or something similar) is only used if you
need host-to-host security or session continuity in the face
of network outages or mobility.  That is, if you are likely
to converse with the same host for a longer time, it makes sense
to pay the performance penalty you have to do in order to set up
the ID -> locator mapping state, and if you don't, you use locators
as proxy IDs.

> For instance, if ESP/AH want to operate with SAs bound to 

I don't understand how this is related to datagram'ish functions,
but you are right, sending a TCP syn requires both the ID and
the locator.  However, I as far as I can understand, the source
network could supply the locator, if that is desired.  (Note that I
am not saying that it was desired, I'm just saying that it probably
could be done in that way.)

>> could be used to implement identifier->locator mapping, if really

I haven't found *the* paper about DHTs yet,
here are a couple:

Sylvia Ratnasamy, Scott Shenker and Ion Stoica,
"Routing Algorithms for DHTs: Some Open Questions",
IPTPS'02, http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf

Emil Sit and Robert Morris, "Security Considerations for
Peer-to-Peer Distributed Hash Tables", IPTPS'02,
http://www.cs.rice.edu/Conferences/IPTPS02/173.pdf

Maybe there is somebody on the list who knows DHTs better?

--Pekka Nikander

---

From: "Craig A. Huegen" <[email-masked]>
Date: Mon, 18 Nov 2002 11:51:05 -0600 (Central Standard Time)

My sincere apologies for replying to a topic that's 2 weeks old...
Catching up...

>      e.g. for traffic engineering,

I can agree with this if the "network" system included the
identifier->locator mapping component, such that policy could be centrally
maintained within said "network".

Of course, link/path state would also have to be communicated to this same
component so that it can update the selection algorithm based on current
topology conditions.

That system would be responsible for selecting the proper locator based
upon the operators' policy -- whether it's to prefer a path because one of
my multi-homing connections is much less expensive, or because it's
generally a better network, or whatever.

Performing path selection based on left-side most matched bits between a
set of source locators and destination locators still has its drawbacks,
though, so I think there is a need for robustness in network visibility --
the multihomed end-user may need to receive routing table feeds from its
service providers to accomplish its policy objectives.

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..