Subject: Re: [arch-d] Benefits of identity/location separation?

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Apr 2007 12:01:22 -0400 (EDT)

> From: John Day <[email-masked]>

    > The loc is a point of attachment address

Yes; it's also commonly called the interface "address". (And BTW I don't
like to use the term "address", because to too many people it means "IPvN
address", i..e. something with very complex/mixed semantics.)

    > the id is seems to be an application name .. Strictly speaking it is
    > probably more an "application-protocol-instance-name" rather than an
    > application name since it seems to identify a single
    > flow/connection/communication to an application. Although in some
    > proposals the id seems to be a "transport address" (whatever that
    > could be)

No, as far as I know, most people think it names a host/stack, i.e. an
instance of a group of transports (TCP, UDP, etc), and all the connections
of that group instance.

As John Leslie pointed out, this is yet *another* axis of confusion with
IPvN addresses - not only location/identity (semantics of name), but also
interface/host (what is named).

    > If what you mean by "stack name" is what I think you mean by stack
    > name, ;-) then I think they need to be location-dependent in some way
    > without being route dependent.

First, I disagree that stack-names need to be location-dependent. Why would
you want that, iff interface-name (PoA-names) are also location-dependent?

Second, location-names in general (other than source routes) try to be
location-dependent without being route dependent. To give a simple example
of this, you can use them to say what the destination is, but from any
location in the network.

Also, in a classical ideal routing architecture, no place in the network
would have more than one location-name. (This is equivalent to saying that,
at any given layer of abstraction naming, abstraction boundaries
constructed around portions of the graph do, or do not, overlap. If they do
overlap, any location in that overlap can have more than one
location-name.) And even if a location did have more than one
location-name, those location-names would be route-independent (i.e.
traffic from one location to another would take the same path no matter
which location-name(s) were used).

In real networks (especially ones that are much, much bigger than the ones
Jerry had to look at when he did 1498), *neither* of these is true any
longer.

So the concept of "location-dependent ... without being route dependent" is
no longer applicable - *anything* which is location-name-dependent is
inherently no longer route-independent.

    > This being what 1498 calls node *address.* Not a node name.

I haven't read 1498 recently, but it's rather old (the original dates to
1982, and it's possible that our understanding has become more subtle since
then. As one example, I long ago decided that at the level above interfaces
(PoA's) we should be naming stacks, not physical machines. So I don't agree
that giving stacks/hosts names which include their location is a good idea
- in fact, I would extremely strenuously disagree.

    > Then I guess if you think "stack name" is node address, then I think
    > it has the wrong properties! ;-) And we are in for scaling problems.

And I still have no clue whatsoever that these scaling problems might be.
Please expand your allusion.

       Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 26 Apr 2007 12:51:22 +1200

> interface/host (what is named).

I think the HIP implementers are quite clear on what we think is  
identified: whatever the administrator wants.  It could be the  
endpoint of anything from the entire host's connection bundle, to an  
application's connections, to a single connection.  In practice, by  
default it ends up being the first, but that is not necessary either  
in theory, or in practice.

I recall a hallway discussion about parallel OSes where process  
migration is possible, and how that would interact with HIP, and we  
concluded that if an identity were bound to an application, it is  
entirely reasonable for that identity to follow the process around...  
and having HIP there makes that somewhat easier.

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Apr 2007 08:50:49 +0200

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer
Internet Standards and Technology
IBM

On 2007-04-26 02:51, Andrew McGregor wrote:
> identified: whatever the administrator wants.  It could be the endpoint 
> of anything from the entire host's connection bundle, to an 
> default it ends up being the first, but that is not necessary either in 
> theory, or in practice.
> 

I think this is pretty much standard practice in some of today's
Virtual IP(v4) Address solutions. And imagine a large server farm
of the future, with a pool of physical network interfaces shared
by a larger pool of (multicore) CPUs in a big rack. With a plethora
of IPv6 addresses or HITs available, you can easily imagine that the
correspondence between an identifier and an interface or CPU becomes
completely fluid. An instance of IP might well be dedicated to as
little as a single application session in such a system.

     Brian

---

From: John Day <[email-masked]>
Date: Thu, 26 Apr 2007 06:52:48 -0400

I am a bit pressed for time, but I hope this helps.  If I have time 
later I will try to comment on what you said above.

>- in fact, I would extremely strenuously disagree.

Give 1498 a careful re-read.  It is just as correct today as when it 
was written.  There is one minor case that probably didn't exist when 
Saltzer wrote it that he missed (understandably).  But if you include 
it, it turns out to be a very telling indicator of the general 
structure.

As you re-read 1498, construct a logical model of the resulting 
architecture based on what it says not on what we think we have 
today.  Then compare it to what we have today.

One thing you should find is that based on what Saltzer writes, the 
minimum necessary scope of a point of attachment  address is that it 
be unambiguous only between nearest neighbors.

The scope of node addresses is greater, usually "global," but 
strictly speaking doesn't have to be.

Take care,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2007 10:10:44 +0200

John,

> minimum necessary scope of a point of attachment  address is that it be 
> unambiguous only between nearest neighbors.

I can readily believe that as a mathematical theorem. But the question
is whether it's an operationally useful observation.
> 
> The scope of node addresses is greater, usually "global," 

I don't think that's true, given the number of NATs deployed.
I think usually "site-local" is the usual scope today.

I think the interesting question, where Noel and I likely disagree,
is whether having identifier == locator within site-local scope
is a Good Thing or a Bad Thing.

     Brian

> but strictly 
> speaking doesn't have to be.
> 
> Take care,
> John
> 
>>
>>

---

From: John Day <[email-masked]>
Date: Fri, 27 Apr 2007 06:54:51 -0400

At 10:10 +0200 2007/04/27, Brian E Carpenter wrote:
>>minimum necessary scope of a point of attachment  address is that 
>>it be unambiguous only between nearest neighbors.
>

It can be.  Depends on what the lower layer is.  The point was that 
Saltzer's paper is outlining fundamental principles.  It is only by 
understanding the fundamental principles that we gain insight into 
what is really going on here, which then further indicates the nature 
of the solution.

>I think usually "site-local" is the usual scope today.

Precisely.  Which is why I said "usually."  If the node address space 
is not global, then one must relay based on the application name 
which is global.

>is a Good Thing or a Bad Thing.

The problem with the Internet is that it has half an addressing 
architecture.  But then we have known that for 35 years.

Take care,
John

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Apr 2007 11:49:21 -0700

>is a Good Thing or a Bad Thing.

I think "site-local" has been defined in terms of administrative boundaries
rather than the routing system.  During the  discussion of what became RFC
4193, there was a fairly heated exchange over the value of nailing down
what a "site" is.  The unwillingness to do that in terms of the routing system
was pretty telling.  As it stands, I believe there are lots of things that are definable
as "sites" in 4193 or RFC 1918 terms that are not routing scopes at all.  They
are crunchy-on-the-outside/soft-in-the-middle policy scopes in firewalls, NATs,
and the minds of admins.  Having our addressing system and our routing
system additionally strained by this disjuncture has been no help in the past,
and I hope is not a design goal of our future.
			regards,
					Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Apr 2007 10:42:39 +0200

> and I hope is not a design goal of our future.

I think that is completely correct, and at the heart of where John Leslie
has quarrels with my draft.

Firstly let me say that when I update the draft, I will try to bring the
points that John raised to the fore, and restructure the draft to show that
there is a fork in the road to be chosen.

Then, I have to say that I believe that design for the future is strongly
constrained by the past. As the RRG draft says:

    Since solutions that are not deployable are simply academic
    exercises, solutions are required to be deployable.  Furthermore,
    given the extensive deployed base of today's Internet, a solution is
    required to be incrementally deployable.

I see no possible way round this. I have to say that strongly affects my
view of which fork in the road we should take.

     Brian

---

From: John Day <[email-masked]>
Date: Mon, 30 Apr 2007 07:46:24 -0400

>constrained by the past. As the RRG draft says:

I would disagree. I would say that only the next step is strongly 
constrained by the past.  Much of the problem here is that there is 
no clear idea of the goal.  As long as that is the case, all of this 
is nothing more than wandering lost in the woods.  There does not 
even seem to be a clear idea of what North is let alone how to get 
out of the woods.

>    required to be incrementally deployable.

Yes, indeed everything must be ultimately deployable.  However, some 
things may take more than one step.  But I do find this 
characterization that the Internet is "too big" to be changed to be 
bothersome.  We have been hearing this since the early 1980s.  Of 
course, by comparison changes then would have been trivial compared 
to now.  The only for which this rationalization can apply is that 
the Internet is near the end of its growth, rather than still having 
considerable growth to go.

I tend to be in the later camp. We aren't even close to the end of 
its growth, which makes the idea that we can build and maintain 
something that the world economy is now dependent upon without a 
clear picture of where it needs to be evolving to but can only react 
to crises of its limitations discovered 35 years after the fact is 
both frightening and irresponsible.

Take care,
John

---

From: JFC Morfin <[email-masked]>
Date: Mon, 30 Apr 2007 13:55:59 +0200

At 10:42 30/04/2007, Brian E Carpenter wrote:
I see no possible way round this. I have to say that strongly affects my
>view of which fork in the road we should take.

This means that you think we go from a legacy monolith to another 
monolith by way of evolution? Not from a situation A to a situation B 
by way of adaptating whatever is necessary, even if one has to adapt 
from a single monolith architectural understanding and acknowledge 
the multilith nature of the need? "The principle of constant change 
is perhaps the only principle of the Internet that should survive 
indefinitely." (RFC 1958). This does not only affect issues within 
the Internet current approach (as defined in RFC 3935 core values), 
but may lead to change these very core values. At least one is to be 
changed (from "decentralised" to "distributed").

You say "fork in the road", why not to free us once for goo and 
"take-off". Switching from "inter-choice" to "multi-possibility".

I am afraid that all this identity/location debate forgets many 
options. There is some kind of interactive unity between 
understanding your need, identifying who can address is, where that 
who is located, reaching it, staying connected, and keeping your need 
answered. This is a constant mix of fixity (the hardware/bandwidth 
layer), mobility (the software/logic layer), virtuality (the rendered 
service) and continuity (of the pertinent service being obtained), 
the whole thing being dependent upon the constraints/advantages of 
the followed access path (s) and resulting costs.

For example (the reason why I am adamant on language issues), what is 
the need for a user to access a host he cannot understand because it 
uses another language. Or if he has no login/password on it. Or the 
proper services is not offered there (ex. difference between IN and 
MX). Or if his type of traffic is being filtered out or downgraded to 
a lesser quality transport service.

At least identity/location/accessibility should be covered. But 
accessibility can include a very large number of issues interacting 
with identity and location. For example why do Web.2.0 applications 
use zero second TTL to constantly adapt the address of the source of 
web elements? Is the identity or the localtion which is changing in 
that rotational resulting addresses
jfc

---

From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Date: Mon, 30 Apr 2007 07:38:57 -0500

I have been seeing more and more solutions (or at least proposed
solutions) regarding identity/location separation (i.e. shim6, hip,
etc...).  I believe it is extremely important that the identity/location
separator solution work in concert with security solutions such as IPsec
or whatever IPsec may become of that for identity/location separation.
Obviously for mobile and multi-homed systems, the address and the
identity are no longer one in the same.  Running IPsec in such
environments is problematic at best.

Will Ivancic

---

From: Dan McDonald <[email-masked]>
Date: Mon, 30 Apr 2007 08:53:26 -0400

On Mon, Apr 30, 2007 at 07:38:57AM -0500, Ivancic, William D. (GRC-RCN0) wrote:
> I believe it is extremely important that the identity/location

Agreed.  I *believe* most-if-not-all of the folks here in the audience
understand that one can't blow off security anymore.  I also believe IPsec,
even as specified in RFC 430x, would be able to handle a ID/locator split.

> identity are no longer one in the same.

True...

> Running IPsec in such environments is problematic at best.

...not true.

Read the definition of a Security Association in RFC 4301:

   For an SA used to carry unicast traffic, the Security Parameters
   Index (SPI) by itself suffices to specify an SA.

That certainly is agile in the face of an ID/locator split.  I think I'd need
to pull out too much disparate text, but IKEv2 (4306) calls out the traffic
selectors explicitly, so two ends who don't specify locator selectors can
communicate regardless.

Thinking about it, an ID/locator split MAY lead to more flexibile security
policy... "Ooooh, if I go over cloud X I have to worry about more snooping
than I do if I go over cloud Y."  Though in practice, I doubt clouds X or Y
would be that much different.

Dan

---

From: Merike Kaeo <[email-masked]>
Date: Mon, 30 Apr 2007 07:22:03 -0700

IKEv2 and/or Mobike should be able to handle an ID/locator split  
[although I want to check the details to make sure that is absolutely  
the case] but can IPsec AH handle the ID/locator split?  While there  
are camps that believe AH is deprecated, and of course you cannot use  
it with IPv4 NATs, there was a long discussion in IPv6 mailing lists  
(non-IETF) regarding requiring AH for specific use cases.  There was  
some talk of requiring a 'new AH' to handle a future ID/locator  
split....

- merike

---

From: Dan McDonald <[email-masked]>
Date: Mon, 30 Apr 2007 10:25:32 -0400

On Mon, Apr 30, 2007 at 07:22:03AM -0700, Merike Kaeo wrote:
> the case] but can IPsec AH handle the ID/locator split?

Ahhh, now THAT's an interesting question.

> While there are camps that believe AH is deprecated, and of course you
> cannot use it with IPv4 NATs, there was a long discussion in IPv6 mailing
> lists (non-IETF) regarding requiring AH for specific use cases.  There was
> some talk of requiring a 'new AH' to handle a future ID/locator split....

I'm not sure if a "new AH" would be needed, but rather a "new AH rules for
new IP protocol".

Assuming the ID/locator split is technically a new IP header (v9?), all one
would need is a processing rule for AH that says "don't include the locator
in the AH computation".  If the split is a change to IPv6, then I suppose
there could be an SA attribute (negotiated by IKE, or say an SADB_X_SAFLAG_
value for PF_KEY) that says "don't include locator part of IPv6 header".

It shouldn't be that hard to make AH work in a post-split world.  Protocol
designers in the audience - please take note that AH still matters to some
people.

Dan

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Apr 2007 08:29:17 -0700

> or whatever IPsec may become of that for identity/location separation.

IPvLX has designed-in provisions for securing mechanisms.
A new version of the draft is now available at:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-07.txt

Fred
[email-masked]

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 1 May 2007 11:31:47 +1200

> designers in the audience - please take note that AH still matters  

The same trick as is used by HIP's BEET mode for ESP would work;  
require that the locators in the header be rewritten to identifiers  
(or hashes thereof) before doing crypto or checksums.

Or, use ESP with null encryption and authentication enabled (yes, I  
know this is regarded as a bad idea... but it does work).

Andrew