Subject: [RRG] On "jack-down" models

From: "Tony Li" <[email-masked]>
Date: Sun, 16 Mar 2008 02:15:44 -0700

Hi all,

Here's a few thoughts on segmenting the solution space a bit more.

As part of our original charter, we accepted as axiomatic that the
overloading between the locator and identifier namespaces was harmful.  We
ended up in this difficulty because the address was used by the transport
protocols as part of a host's identification, as well as the topological
locator that was used by the routing subsystem to forward packets.  We've
also accepted as axiomatic that we would like to separate this functionality
into two independent namespaces.  I want to stress here that for the
architectural result to be in any way clean, independence is mandatory.  Any
linkage whatsoever would be a clearly suboptimal result.

In what Noel has characterized as the "jack-up" model, we would lift up the
operating Internet today, let what we think of as addresses continue to be
used, but demote them to the role of pure identifiers.  We would then
install a new namespace of locators underneath it, provide a mapping between
identifiers and locators, and work out a forwarding plane adaptation so that
we only dealt with locators in the core.  

The logical alternative to this is to continue to use addresses, but instead
of as identifiers, to retain them as locators.  This would imply that we
would introduce a new namespace to function as identifiers.  In effect, this
is part of what Handley's proposal does: by shifting the transport to stop
using addresses as part of the identification of a transport connection, it
creates the need for another level of identification.  Handley posits the
use of multiple parallel connections between hosts, striping data across
these connections to instantiate a single, address-agile transport layer.
Implicit in this structure is a mechanism for the host to recognize that
these individual connections are part of a greater aggregated connection.
This has obvious security implications which will, in effect, require a
security association between hosts.  That security association effectively
requires some security token (e.g., a public-private key pair used to
compute a session key) so that the correspondent host can be assured that
the component connections are indeed related.  This security token is, for
all intents and purposes, a host identifier.  Accordingly, it seems
appropriate to christen this the "jack-down" model, as it jacks the network
layer down a notch and inserts a layer of host identification above the
network layer, leaving it firmly embedded in the transport layer.

Assuming that we retain our axioms from the start of this discussion, this
pretty clearly divides the solution space in two, and would seem to present
a full cover of the space, which I, for one, find somewhat satisfying.

Comments?  Thoughts?

Regards,
Tony

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Robin Whittle <[email-masked]>
Date: Sun, 16 Mar 2008 23:35:20 +1100

Hi Tony,

You wrote, in part:

> We've also accepted as axiomatic that we would like to separate
> this functionality into two independent namespaces.  I want to
> stress here that for the architectural result to be in any way
> clean, independence is mandatory.  Any linkage whatsoever would be
> a clearly suboptimal result.

If this is a discussion about practical solutions, then I think
incremental deployability is a principle which is more important
than any other.

I don't think any of the map-encap approaches - LISP, APT, Ivip or
TRRP - involves the creation of a completely independent namespace.
 I can't imagine any incrementally deployable solution which would.

I can't imagine how a "jack-down" system such as you describe could
be incrementally deployable, or how the system could support the
instantaeous delivery of packets the Net can do today, without prior
arrangement, since you mention key pairs for session keys for
encrypting the traffic.

Since you ask whether this division into "jack-up" and "jack-down"
covers every possible solution, and since I don't recognise the
current map-encap schemes as matching "jack-down", I am trying to
imagine how they match your "jack-up" description.

I don't think they do.

So if your problem space ignores incremental deployability as a
consideration and assumes architectural cleanliness, then maybe your
split is correct.

However, if your solution space doesn't insist on complete
architectural cleanliness, and the existing map-encap proposals
would fit within this space, them I wonder whether they are within
the "jack-up" class, or whether some new division is required.

> we only dealt with locators in the core.  

None of the map-encap schemes involve a truly new namespace for the
ETR addresses - ETRs are located on some subset of the address space
which is not itself subject to mapping by ITRs.

Theoretically, one might be able to deploy the map-encap scheme to
the point where no host every used a non-mapped space, and that only
routers, including ETRs and BGP routers, used this non-mapped space.

But in all these map-encap schemes hosts can still send packets to
the ETRs, because they are addressable as ordinary IP addresses -
unless some kind of filtering fence is erected everywhere to stop
"hosts" sending packets to or from any device in "locator space",
which might be the case with fully deployed APT.

I regard the goal of complete separation of locator and identifier
spaces as unnecessary and counter-productive.

For instance, some hosts are part of the support system for the
map-encap scheme, and they need to be on non-mapped (RLOC) addresses
to avoid circular dependencies.  Yet those hosts need to talk to
hosts which use mapped addresses - so the idea of complete
separation makes no practical sense to me.

I conclude that if your solution space is limited to architecturally
pure outcomes, then it almost certainly cannot include solutions
which are incrementally deployable.

If your solution space includes all solutions which are
incrementally deployable, then I think it must include architectures
which are not completely clean.

I am only really interested in incrementally deployable solutions.

  - Robin

---

From: [email-masked]
Date: Sun, 16 Mar 2008 10:05:54 EDT

Further thoughts related to the separation between identfier information  and 
routing/location information:
As far as I know, by the enum-solution for VoIP the telefone  number is 
treated like a DNS-name and mapped to an IP address. 
 
By means of a thorough loc-id split, i.e. by providing 2 destination  info 
parts, the identifer part may be extended to cater multiple address  families, 
e.g. E.164 immediately.
 
Also VPN numbering may be done in a more elegant way, enabling better (?)  
VPN models. Or AFI's for new sorts of entities ? like traffic lights? etc etc  
etc.
 
Loc-id separation makes a lot of  sense for the benefit of both the  
identifiers and their categories as well as the routing. 

Heiner

In einer eMail vom 16.03.2008 10:18:54 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  all,

Comments?   Thoughts?

Regards,
Tony

---

From: "Victor Grishchenko" <[email-masked]>
Date: Sun, 16 Mar 2008 19:50:47 +0500

It seems, you exclusively assume incremental as-an-upgrade
deployability. There are also other scenarios. Take Ethernet,
for instance. It incrementally ate a lot of competing/legacy
technologies without compromising own architectural purity.
Hypothetically, if some new **layer** of routing is able to
a) substitute the need for "serious tools" (AS, PI addresses)
b) eat other layers upwards and downwards
Then you'll get both purity and incremental deployment.
Just a counter-example.

-- 
Victor

---

From: "William Herrin" <[email-masked]>
Date: Sun, 16 Mar 2008 12:23:40 -0400

On Sun, Mar 16, 2008 at 5:15 AM, Tony Li <[email-masked]> wrote:
>  overloading between the locator and identifier namespaces was harmful.

Hi Tony,

I wasn't around when the group was chartered, but my knee-jerk
reaction to this statement is: have we learned nothing from IPv6?

9/10ths of IPv6's deployability problem stems from the insistence on
using new number resources instead of extending the old ones.
Deploying the new number resources is proving to be a much harder and
more expensive problem than developing and deploying the protocol
software. The effect on IPv6's deployment has been exceptionally
harmful.

>  of as identifiers, to retain them as locators.

I respectfully submit that the most logical course of action is to
retain EIDs as identifiers but within upgraded parts of the system,
restrict which EIDs are able to take on the task of both identifier
and locater. I'm very curious what desirable functionality that would
exclude and what undesirable functionality such an approach would
require. I'm not seeing it off the top of my head.

>  technologies without compromising own architectural purity.

Victor,

Ethernet was usually the first LAN technology deployed at a location.
It tended to arrive late at locations which had something else first
and faced great resistance where the incumbent deployment was large.

Situationally, we're talking apples and oranges.  Our routing solution
will almost always have to either displace or supplement an incumbent
technology. If the former, it had better be able to do so in a manner
compatible with the deployer's neighbors, clients and suppliers. If
the latter, it had better offer enough new capability to merit the
additional expense.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: David R Oran <[email-masked]>
Date: Sun, 16 Mar 2008 15:12:03 -0400

> a full cover of the space, which I, for one, find somewhat satisfying.
For proposals that involve host protocol stacks as a mandatory part of  
the solution space, it certainly would help me to have an objective,  
comprehensive comparison of:
a) HIP
b) multi-address transports, including both SCTP machinery and  
Handley's proposal
c) six-one
d) 32+16 (Rosenberg's IPv4+NAT solution).

I agree with a couple of the posts that understanding the incremental  
deployment dynamics of thee proposals is very important, especially if  
the penetration never gets near 100%.

DaveO.

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 16 Mar 2008 12:36:43 -0700

Earlier, Tony Li wrote (in part):
% ...
% This has obvious security implications which will, in effect, require a
% security association between hosts.  That security association effectively
% requires some security token (e.g., a public-private key pair used to
% compute a session key) so that the correspondent host can be assured
% that the component connections are indeed related.

It is unclear to me that one needs to have a cryptographic security
association in all cases, or indeed even in common deployments.

For example, an unpredictable nonce present in control traffic (rather
than in every packet) could provide security protection against off-path
attackers that is entirely equivalent to the security provided by ordinary
IPv4 or IPv6 for sessions not using IP Security.  In such a model,
the nonce would be the "security token", but it would not be derived
from any session key, from any public/private key, or from any
public/private key pair).

% This security token is,  for all intents and purposes, a host identifier.
% ...

It isn't obvious to me that the claim above is necessarily true.
Using the example of a nonce, the nonce might be very short-lived
(e.g. for the duration of a single IP session or flow) and hence
not be suitable for use as a node identifier.  Further, if there
were significant potential for a nonce collision between different
flows/sessions, then one might want to have some method to
differentiate among the sundry sessions using a given nonce
value.

HIP makes the identity of a node a function of the public key of the node.
A corollary to that practice seems to be that if a node's public key were
compromised, and in my experience all cryptographic keys are eventually
compromised, then the node necessarily would lose its identity.

So it seems distinctly undesirable (to me) for the identity of a node
to be derived (directly or indirectly) from any cryptographic key used
by that node.

Instead, I'd prefer to have the cryptographic keys used by a node
(if any) bound to the identity of the node using some other method.
One example might be some sort of X.509v3 (PKIX) certificate, but
other examples can be imagined.

If one wants to use an identity that is derived from a cryptographic
key, then looking at the HIP RG's architectural work might be very
relevant.

Cheers,

Ran
[email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 16 Mar 2008 22:02:54 +0200

> % requires some security token ... so that the correspondent host  
> can be assured
> For example, an unpredictable nonce present in control traffic ...   
> In such a model,
> the nonce would be the "security token", but it would not be  
> derived from any session key, from any public/private key, or from  
> any public/private key pair).

Alternatively, as a middle ground between a public key and a simple  
token would be various techniques based on reverse hash chains and  
other similar methods.  TESLA-like, if you will.  LHIP is one option  
in that space.

> not be suitable for use as a node identifier.

I agree.

> compromised, then the node necessarily would lose its identity.

That is how the HIP architecture has been written today.

However, there is some work on using separate node-level or  
application-level identifiers (still preferably but not necessarily  
public keys), separate from the HIP-layer HI, and then using  
(delegation) certificates to bind these identities to the HIs, with  
channel bindings.  That work hasn't found its way to internet-drafts  
yet, though.  (I know a few people have talked about writing IDs in  
that space, but I haven't seen any published yet. But maybe I've just  
missed that.)

> other examples can be imagined.

But then you just shift the burden to the secrecy of the CA private  
key.  That is, if all keys are eventually compromised, what do you do  
when the CA private key gets compromised? You have to reconfigure all  
hosts, I guess.

To me, it would be better to not to concentrate the trust too much.   
If (manual) reconfiguration is inevitable, it might pay off to make  
sure that a) its probability is minimised and b) when it happens,  
only a small fraction of all hosts are affected.  Hence, maybe  
threshold certs at the top of the tree, or a forest instead of a  
single tree, or both?

--Pekka Nikander

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Mar 2008 11:09:13 -0700

> would introduce a new namespace to function as identifiers.  In  

Tony, that is what we recommend in LISP. So we don't have to re- 
address the core. We force the re-addressing of sites that don't  
currently have PI blocks. We also are loose about stating that sites  
can use PA blocks for EIDs. But with the later, the namespace is not  
mutually exclusive. That is okay, if the two never cross.

Having said that they will cross for IPv4 if LISP-NAT is used, but if  
LISP-PTR is used, the namespaces can be as separate as they are in  
multiple VRFs.

But using a single "super-prefix" with IPv6, we can have a much  
cleaner separation of the namespaces. Hence, the draft draft-meyer- 
lisp-eid-block-00.txt where we propose to request IANA to allocate an  
IPv6 /16.

> these individual connections are part of a greater aggregated  

You get that as well when middle-boxes load-split ingress and egress  
traffic. The transport connection in the host just sees a 32-bit value  
as a connection ID.

> network layer, leaving it firmly embedded in the transport layer.

I don't see this mechanistically any different than Shim6 or Six/One.  
I look forward to more details of Mark's proposal so we can see the  
differences.

Dino

---

From: Scott Brim <[email-masked]>
Date: Sun, 16 Mar 2008 20:51:16 -0400

On 3/16/08 5:15 AM, Tony Li allegedly wrote:
> Handley posits the
> all intents and purposes, a host identifier.  

I question the very last step.  The various multiplexed transport layer 
connections are unified by something at or above their level.  Therefore 
an identification/authentication mechanism to unify them could be, 
perhaps should be, at a higher layer.  It could be a transport-layer 
identity for the entire host, but certainly doesn't need to be.  In fact 
I don't see a *requirement* for a network-layer or even transport-layer 
identity to be used in end-to-end authentication (routing yes).

 > Accordingly, it seems

"Jack-up" removed location from the IP address by introducing another 
relationship (edge-to-edge, ITR-ETR) below it.  "Jack-down" would remove 
identity by introducing another relationship (e2e, authentication 
function) above it.  The terminology seems reasonable and I can see why 
you would like the symmetry, but I'm not sure it's useful. :-)

First, there are intermediate schemes, for example those that do not 
remove all "address" functionality from EIDs but still use them for 
locally scoped routing.

Second, as I said above, I am quite unsure that the old way of thinking 
of general purpose end system IDs is actually useful.  We can have 
network-layer identities, or transport-layer ones, but what will we use 
them for?  The IP layer itself doesn't care what addresses are on the 
packets it receives.  It's only higher layers that care.  I'm on the 
verge of invoking the end-to-end argument, because it seems that as time 
goes on our needs for sophistication in higher layer identification and 
authentication increase, and that the transport layer shouldn't provide 
identity and authentication for its client layers, because in the future 
it won't be able to do an adequate, specific-enough job of it.

So we could have the very nice symmetric distinguisher of 
jack-up/jack-down, but it implies that the use of network-layer (maybe 
transport-layer) identifiers is architectually fundamental.  I get the 
feeling that our thinking is evolving away from that.

I'll try to come up with other fundamental criteria instead.

Scott

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2008 06:28:32 +0200

Scott,

I mostly agree with you (with some caveats of whether I understand  
you correctly).   Where I perhaps disagree is in the need for network- 
layer end-to-end non-routing identifiers.  They are quite useful.   
See below.

>> [Jack down] has obvious security implications which will, in  
>> effect, require a security association between hosts.  That  
>> security association effectively requires some security token  
>> (e.g., a public-private key pair used to compute a session key) so  
>> that the correspondent host can be assured that the component  
>> connections are indeed related.  This security token is, for all  
>> intents and purposes, a host identifier.
>
> I question the very last step.  The various multiplexed transport  
> layer connections are unified by something at or above their  
> level.  Therefore an identification/authentication mechanism to  
> unify them could be, perhaps should be, at a higher layer.  It  
> could be a transport-layer identity for the entire host, but  
> certainly doesn't need to be.  In fact I don't see a *requirement*  
> for a network-layer or even transport-layer identity to be used in  
> end-to-end authentication (routing yes).

While I can easily see architectures where such network-layer or  
transport-layer identities do not exist, especially the network-layer  
ones are quite useful.

Specifically, network-layer host-to-host identifiers make a) host- 
based mobility and b) host-based multi-homing (aka multi-access)  
easier especially in the multi-operator (roaming) situations.   
However, for such use the network-layer identifiers can be both  
anonymous (not bound to a real-world identity) and ephemeral.  They  
need to be cryptographically relatively strong, though, i.e. at least  
composed of several tokens or, preferably, based on hash chains or  
shared secrets.

> "Jack-up" removed location from the IP address by introducing  
> another relationship (edge-to-edge, ITR-ETR) below it.  "Jack-down"  
> would remove identity by introducing another relationship (e2e,  
> authentication function) above it.  The terminology seems  
> reasonable and I can see why you would like the symmetry, but I'm  
> not sure it's useful. :-)

And the offered functionality may not differ that much, in the end.   
In the jack-up case the "split" is in the network, but but a host can  
be considered a part of the network.  In the "jack-down" case the  
split is in the host, but the host can be "extended" to a local ETR/ 
ITR by "adding" a local IP-connection "within" the (conceptual)  
host.  That is all in
http://datatracker.ietf.org/drafts/draft-nikander-ram-generix-proxying/

> First, there are intermediate schemes, for example those that do  
> not remove all "address" functionality from EIDs but still use them  
> for locally scoped routing.

I think (but haven't checked) the generix draft covers some such cases.

> Second, as I said above, I am quite unsure that the old way of  
> thinking of general purpose end system IDs is actually useful.  We  
> can have network-layer identities, or transport-layer ones, but  
> what will we use them for?

They are very useful for host mobility and multi-access.   
Architecturally, their economic value derives from them allowing a  
host a better capability of choice between operators in a multi- 
access situation.

> The IP layer itself doesn't care what addresses are on the packets  
> it receives.  It's only higher layers that care.  I'm on the verge  
> of invoking the end-to-end argument, because it seems that as time  
> goes on our needs for sophistication in higher layer identification  
> and authentication increase, and that the transport layer shouldn't  
> provide identity and authentication for its client layers, because  
> in the future it won't be able to do an adequate, specific-enough  
> job of it.
>
> So we could have the very nice symmetric distinguisher of jack-up/ 
> jack-down, but it implies that the use of network-layer (maybe  
> transport-layer) identifiers is architectually fundamental.  I get  
> the feeling that our thinking is evolving away from that.

I agree.  I do think that in the long run we are moving away from end- 
to-end, towards some kind of trust-to-trust architectures [Dave  
Clark].  But I'm afraid that such practises are at least 10 years in  
the future.  And even there ephemeral, crypto-strong node-to-node  
identifiers may be very useful.  However, I do think that a HIP-like  
intermediate step towards such architectures is probably very  
useful.  It will take quite a long before the upper layers will be up  
to the task of really managing trust-to-trust.

--Pekka Nikander

---

From: "Tony Li" <[email-masked]>
Date: Mon, 17 Mar 2008 01:13:44 -0700

Hi Robin,

|I can't imagine how a "jack-down" system such as you describe could
|be incrementally deployable, or how the system could support the
|instantaeous delivery of packets the Net can do today, without prior
|arrangement, since you mention key pairs for session keys for
|encrypting the traffic.

Please note that I was suggesting that was going to be part of Mark's
approach.  It's not intrinsic to all jack-down approaches.

|Since you ask whether this division into "jack-up" and "jack-down"
|covers every possible solution, and since I don't recognise the
|current map-encap schemes as matching "jack-down", I am trying to
|imagine how they match your "jack-up" description.
|
|I don't think they do.

Interesting.  So where do they fit?

|So if your problem space ignores incremental deployability as a
|consideration and assumes architectural cleanliness, then maybe your
|split is correct.

I'm interested in trying to characterize the full solution space, including
the good, the bad, and the ugly.

|None of the map-encap schemes involve a truly new namespace for the
|ETR addresses - ETRs are located on some subset of the address space
|which is not itself subject to mapping by ITRs.

Well, I'd claim that they are indeed a new namespace, or at least could be
if the proposals were generalized.  To see that this is possible, consider a
case where we used some other new network layer for doing the encap.
Imagine, for example, that LISP used v6 to encap v4.  As far as I can tell,
logically, the entire proposal still works.  [Yes, I'm sure there would be
bugs, that's not what I'm after...]

|I regard the goal of complete separation of locator and identifier
|spaces as unnecessary and counter-productive.

Please note that my goal was 'independence', not separation.  I have no
problem with some nodes having points in both namespaces.  That's not a big
deal.  The interesting property to me is that one should be able to function
within one namespace without resulting in changes to the other namespace.

For example, one could embed their v4 identifier into their v6 locator.
This would create a coupling between the locators and identifiers that I
would expect would cause problems.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 17 Mar 2008 11:05:53 +0100

> would expect would cause problems.

I don't know the real meaning of adopting v6 address as locator space, in
fact, we can adopt global IPv4+local IPv4 (see IPNL) or LD ID+IPv4 (see HRA)
scheme to extend IPv4 address space, which are relatively lower cost for
deployment. However, I do believe we need a new namespace for identifier
which can provide enough space in a long run, for example, IPv6( or CGA like
address format), E.164, HIT (flat label in HIP). These names (including IPv6
address) are ONLY used as identifiers.

Best wishes,
Xiaohu XU

---

From: Scott Brim <[email-masked]>
Date: Mon, 17 Mar 2008 13:54:22 -0400

> bugs, that's not what I'm after...]

Right.  Or we could run the jackup with DECnet IV.  Or we could run IPv6
in the core and connect islands of XNS over it, or some completely new
protocol.  Adding a jackup layer gives you tremendous freedom, and
potential for Internet evolution (incremental, too).

However, where we're running IP over the same version of IP :-), I think
we're still uncertain about whether we want complete decoupling.  Having
non-overlapping namespaces in map-n-encap means: (1) Devices at the edge
can directly address some special well-known core devices.  This could
solve some so-far-unthought-of bootstrapping problems.  (2) You can put
the mapping points anywhere you want, you can even put multiple ones in
series, and still have only one encapsulation take place.  So for
example if my ISP has decided to "help" me by putting an ITR in my town,
I can still run my own ITR and control my packets.  This works only if
the ISP's ITR recognizes RLOCs as RLOCs in the headers I put on my
packets.  So there are potential benefits either way.

Scott

---

From: "Tony Li" <[email-masked]>
Date: Mon, 17 Mar 2008 19:04:47 -0700

Dino,

|Tony, that is what we recommend in LISP. So we don't have to re- 
|address the core. We force the re-addressing of sites that don't  
|currently have PI blocks. We also are loose about stating that sites  
|can use PA blocks for EIDs. But with the later, the namespace is not  
|mutually exclusive. That is okay, if the two never cross.

Thanks for the correction.  

|> Handley  
|> posits the
|> use of multiple parallel connections between hosts, striping data  
|> across
|> these connections to instantiate a single, address-agile transport  
|> layer.
|> Implicit in this structure is a mechanism for the host to recognize  
|> that
|> these individual connections are part of a greater aggregated  
|> connection.
|
|You get that as well when middle-boxes load-split ingress and egress  
|traffic. The transport connection in the host just sees a 
|32-bit value  
|as a connection ID.

Ok, but you don't get to take advantage of the parallel paths between the
end host and the middle box(es).  

Think of all of the time and effort that folks have put into ECMP routing.
Doesn't it make some sense that they will want to eventually propagate this
all the way back to the host?

|I don't see this mechanistically any different than Shim6 or Six/One.  
|I look forward to more details of Mark's proposal so we can see the  
|differences.

If I understand it, there's a drastic difference.  First, all of the
multihoming issues are dealt with by layer 4 (and possibly above).
Individual transport connections would just use vanilla v4 addressing as
it's used today, complete with using the address as identification for the
component connection.  These would then get tied together by a stat. muxing
layer.

That would leave routing completely and wholly unchanged, and allow upgraded
hosts to migrate to pure PA addressing without issues.  Upgraded hosts could
still interoperate with legacy hosts using legacy transport mechanisms.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 17 Mar 2008 19:24:26 -0700

Hi Scott,

|> This has obvious security implications which will, in 
|effect, require a
|> security association between hosts.  That security 
|association effectively
|> requires some security token (e.g., a public-private key pair used to
|> compute a session key) so that the correspondent host can be 
|assured that
|> the component connections are indeed related.  This security 
|token is, for
|> all intents and purposes, a host identifier.  
|
|I question the very last step.  The various multiplexed 
|transport layer 
|connections are unified by something at or above their level.

Agreed.

|Therefore 
|an identification/authentication mechanism to unify them could be, 
|perhaps should be, at a higher layer.  It could be a transport-layer 
|identity for the entire host, but certainly doesn't need to 
|be.  

Agreed.  Further, it could be session specific, and, as Ran noted, as
lightweight as a nonce.

|In fact 
|I don't see a *requirement* for a network-layer or even 
|transport-layer 
|identity to be used in end-to-end authentication (routing yes).

Fair, yet the ability to associate one connection to another implies that
there is some identification functionality that must be exchanged between
end hosts.  If you want to call it session layer, I won't argue.
Authentication isn't sufficient, as two end hosts might have multiple
aggregated transfers between them and you still need a mechanism to
associate a connection to a session.

|"Jack-up" removed location from the IP address by introducing another 
|relationship (edge-to-edge, ITR-ETR) below it.  "Jack-down" 
|would remove 
|identity by introducing another relationship (e2e, authentication 
|function) above it.  The terminology seems reasonable and I 
|can see why 
|you would like the symmetry, but I'm not sure it's useful. :-)

I'm just trying to ensure that we've covered the solution space in some kind
of reasonable way.  I know you know this, but I consider it basic due
diligence on our part as researchers to honestly explore the solution space
in some kind of systematic way.

|I'm on the 
|verge of invoking the end-to-end argument, because it seems 
|that as time 
|goes on our needs for sophistication in higher layer 
|identification and 
|authentication increase, and that the transport layer 
|shouldn't provide 
|identity and authentication for its client layers, because in 
|the future 
|it won't be able to do an adequate, specific-enough job of it.

Excellent point, thank you.

|So we could have the very nice symmetric distinguisher of 
|jack-up/jack-down, but it implies that the use of network-layer (maybe 
|transport-layer) identifiers is architectually fundamental.  I get the 
|feeling that our thinking is evolving away from that.

Interesting.  If that's the case, then the implication is that we don't
really need a locator/identifier split at all, as we don't need the
identitfier.

|I'll try to come up with other fundamental criteria instead.

I look forward to it.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Mar 2008 11:39:03 -0700

> Thanks for the correction.

Your welcome.

> end host and the middle box(es).

Well that is an IGP policy that is already implemented in most sites  
today. You can ECMP from each IGP router on 0.0.0.0/0 to each ITR. So  
that problem is already solved.

And LISP doesn't change that.

> all the way back to the host?

It is propagated to the first-hop router. In fact, we are even adding  
techniques to get shortest paths from a source to the first-hop router  
when there is a multi-hop switch network between the two.

> component connection.  These would then get tied together by a stat.  

That is a shim6 approach IMO.

> still interoperate with legacy hosts using legacy transport  

In LISP routing is left unchanged in the site and in the core. The  
mapping function is what is added and only in the CE boxes.

Routing is really not changing. If it did we couldn't do the LISP  
pilot over the Internet right now. And many of us are doing this pilot  
in a corporate environment where the IT department has no idea what we  
are doing, hence no site changes.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Mar 2008 00:02:40 -0700

Dino,

|> Ok, but you don't get to take advantage of the parallel paths  
|> between the
|> end host and the middle box(es).
|
|Well that is an IGP policy that is already implemented in most sites  
|today. You can ECMP from each IGP router on 0.0.0.0/0 to each ITR. So  
|that problem is already solved.

Sorry, I'm making a different point.  In Mark's proposal, there are multiple
parallel transport connections, each of which could in turn benefit from
ECMP.  The point is that within the domain and outside of the domain, his
approach can make use of ALL of the available parallel paths.  That's not
possible for any single transport connection.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 27 Mar 2008 11:01:08 -0400

On 3/17/08 12:28 AM, Pekka Nikander allegedly wrote:
> Scott,
> 
> I mostly agree with you (with some caveats of whether I understand you 
> correctly).   Where I perhaps disagree is in the need for network-layer 
> end-to-end non-routing identifiers.  They are quite useful.  See below.
> 
>>> [Jack down] has obvious security implications which will, in effect, 
>>> require a security association between hosts.  That security 
>>> association effectively requires some security token (e.g., a 
>>> public-private key pair used to compute a session key) so that the 
>>> correspondent host can be assured that the component connections are 
>>> indeed related.  This security token is, for all intents and 
>>> purposes, a host identifier.
>>
>> layer connections are unified by something at or above their level.  
>> Therefore an identification/authentication mechanism to unify them 
>> could be, perhaps should be, at a higher layer.  It could be a 
>> transport-layer identity for the entire host, but certainly doesn't 
>> need to be.  In fact I don't see a *requirement* for a network-layer 
>> or even transport-layer identity to be used in end-to-end 
>> authentication (routing yes).
> 
> Specifically, network-layer host-to-host identifiers make a) host-based 
> mobility and b) host-based multi-homing (aka multi-access) easier 
> especially in the multi-operator (roaming) situations.  However, for 
> such use the network-layer identifiers can be both anonymous (not bound 
> to a real-world identity) and ephemeral.  They need to be 
> cryptographically relatively strong, though, i.e. at least composed of 
> several tokens or, preferably, based on hash chains or shared secrets.

Hi Pekka.  This feels circular.

Specifically how does a network-layer ID make host-based mobility and
multihoming easier?  I'm wondering about the real need.  Yes, you need
some kind of ID -- does the ID need to be a general one at the network
layer?  It would seem that the naming need is in higher layers, not at 
the network layer per se.

When a host works from multiple IP addresses (either serially or
simultaneously), which functions need to know that this is in fact the
same host?  It's for service continuity.  The IP layer doesn't care. 
Transport might care but won't know how to use the knowledge 
effectively.  (E2E principle within a general-purpose stack.)

It used to be obvious to us that a network-layer node name was
important, but I get the feeling that times have changed and identifiers
are more important higher up the stack.

> And the offered functionality may not differ that much, in the end.  In 
> the jack-up case the "split" is in the network, but but a host can be 
> considered a part of the network.  In the "jack-down" case the split is 
> in the host, but the host can be "extended" to a local ETR/ITR by 
> "adding" a local IP-connection "within" the (conceptual) host.  That is 
> all in

Yes.  That was a useful draft.

>> The IP layer itself doesn't care what addresses are on the packets it 
>> receives.  It's only higher layers that care.  I'm on the verge of 
>> invoking the end-to-end argument, because it seems that as time goes 
>> on our needs for sophistication in higher layer identification and 
>> authentication increase, and that the transport layer shouldn't 
>> provide identity and authentication for its client layers, because in 
>> the future it won't be able to do an adequate, specific-enough job of it.
>>
> I agree.  I do think that in the long run we are moving away from 
> end-to-end, towards some kind of trust-to-trust architectures [Dave 
> Clark].  But I'm afraid that such practises are at least 10 years in the 
> future.  And even there ephemeral, crypto-strong node-to-node 
> intermediate step towards such architectures is probably very useful.  
> It will take quite a long before the upper layers will be up to the task 
> of really managing trust-to-trust.

That's the only substantial reason I can think of to pursue network 
layer identifiers -- identity should be handled by the functions that 
need it, but as long as they can't, we can coddle them by hiding the 
problem from them.

Sorry this took so long.  I'm following up on this thread now.

Scott

---

From: Randall Atkinson <[email-masked]>
Date: Thu, 27 Mar 2008 08:28:25 -0700

Earlier, Scott Brim wrote:
% Specifically how does a network-layer ID make host-based mobility and
% multihoming easier?

It decouples the TCP/UDP transport session state from the location.
So when a node moves location (or its upstream connectivity changes
because one of its several upstream links develops a fault -- which is
really the same thing as moving location), the Transport protocol
session state is not affected by the network-layer location change.

It is entirely analogous to why link-layer mobility works so well
(Transport layer session state does not include link-specific information).

To be fair, there are several approaches to this that (arguably)
are pretty similar:

1) SHIM6
2) GSE/8+8
2b) ILNP
3) Mark H's proposal to modify TCP/UDP behaviour so that the
   network-layer information is not part of the Transport layer
   session state.

In some ways, this reminds me of ancient discussions ("Layer Wars")
about the difference between changes at the top of the
network layer and changes at the bottom of the transport layer.
(Summary: the architecture might be different between those two,
but often the engineering is pretty similar.)

% When a host works from multiple IP addresses (either serially or
% simultaneously), which functions need to know that this is in fact the
% same host?  It's for service continuity.  The IP layer doesn't care.

The IP layer might care.  For example, if a node were single-homed
and changed its location without a "soft handoff", then there needs
to be some method to verify that the location update message
came from the same node one was originally communicating with.

% Transport might care but won't know how to use the knowledge
% effectively.  (E2E principle within a general-purpose stack.)

See above.

> And even there ephemeral, crypto-strong node-to-node

The above quoted material is unclear to me.  Given that all keys are
eventually compromised, I would not want my identity to be some
f(public key or some other key) -- so that a key compromise does not
always lead to a loss of identity.

Yours,

Ran
[email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 27 Mar 2008 17:37:40 +0200

Scott,

>>>> (e.g., a public-private key pair used to compute a session key)  
>>>> so that the correspondent host can be assured that the component  
>>> certainly doesn't need to be.  In fact I don't see a  
>>> *requirement* for a network-layer or even transport-layer  
>> transport-layer identities do not exist, especially the network- 
>> layer ones are quite useful.
>>
>> anonymous (not bound to a real-world identity) and ephemeral.   
>> They need to be cryptographically relatively strong, though, i.e.  
>> at least composed of several tokens or, preferably, based on hash  
>> chains or shared secrets.
>
> This feels circular.

Hmm.  What do you mean with that?  Perhaps one key insight here is to  
make a distinction between identity and identifier.  It is well  
possible to continue to identify an entity even when the identifiers  
are not constant.  For one particular approach, see [1]

> Specifically how does a network-layer ID make host-based mobility  
> and multihoming easier?  I'm wondering about the real need.  Yes,  
> you need some kind of ID -- does the ID need to be a general one at  
> the network layer?  It would seem that the naming need is in higher  
> layers, not at the network layer per se.

It makes it easier by aligning the physical mobility granularity and  
the signalling granularity.

In general, if you want to make mobility signalling efficient, you  
have to make sure that:

1. There is a single anchor point through which all the traffic flows  
during the mobility event (the traffic can flow over more optimal  
route before and afterwards).  Consider FMIP as a (convoluted)  
example.  There the previous AR acts as such anchor point.

2. The only _fast_ signalling needed is between the mobile entity and  
the anchor point.  That is, other signalling such as using more  
optimal routes etc. should be able to wait.

3. Pick the topological location of the anchor point in such a way  
that you minimise the sum of your latencies both at the old and the  
new location.

(Perhaps I should write up the insight above into some publication/ 
draft?)

Deriving from that, if your identifier (static or sequence) uniquely  
identifies the moving entity (e.g. host or subnet), you can minimise  
the signalling required at the time of the mobility event.  (In some  
cases you can make with "null" signalling, i.e., from an information  
theoretic point of view you need no extra bits for the mobility event  
once you've set the scene in a suitable way.)

On the other hand, if you have multiple identifiers in the moving  
entity, you will need more signalling.  Of course, if those  
identifiers are delegable, you can delegate the signalling rights to  
another identifier and circumvent the inefficiency. [2]

> simultaneously), which functions need to know that this is in fact  
> the same host?  It's for service continuity.  The IP layer doesn't  
> care. Transport might care but won't know how to use the knowledge  

I agree (to an extent) [3].

> important, but I get the feeling that times have changed and  
> identifiers are more important higher up the stack.

I agree, with the exception of the efficiency point above.

--Pekka

[1] Jari Arkko, Pekka Nikander, and Mats Näslund, "Enhancing Privacy  
with Shared Pseudo Random Sequences,"  in Security Protocols, 13rd  
International Workshop, Cambridge, 20-22 April, 2005.
[2] Pekka Nikander and Jari Arkko, "Delegation of Signalling Rights,"  
in Security Protocols, 10th International Workshop, Cambridge, UK,  
April 16-19, 2002, LCNS 2845, pp. 203-212, Springer, 2003.
[3] Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo, "Effects of  
Mobility and Multihoming on Transport-Layer Security," in Proceedings  
of IEEE Symposium on Security and Privacy, Berkeley/Oakland,  
California, May 9-12, 2004, IEEE Computer Society.

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 27 Mar 2008 17:43:33 +0200

Ran,

A couple of remarks.

>    network-layer information is not part of the Transport layer

Please add to the list HIP mobility & multi-homing, see RFC5201- 
RFC5206 (as they appear any day now).

> network layer and changes at the bottom of the transport layer.

And, besides, e.g. John Day convincingly argues that the "layer  
boundary" between network and transport is a mistake (and I concur  
with him).  [1]

> always lead to a loss of identity.

First, identity != identifier.  Second, have you missed all that I've  
written about delegation and HIP?

--Pekka

[1] John Day.  Patterns in Network Architecture.  Prentice Hall.   
January 2008.

---

From: "Tony Li" <[email-masked]>
Date: Thu, 27 Mar 2008 13:20:26 -0700

|Earlier, Scott Brim wrote:
|% Specifically how does a network-layer ID make host-based mobility and
|% multihoming easier?
|
|It decouples the TCP/UDP transport session state from the location.

At the risk of simply summarizing what Pekka and others have said, the key
point that I'm getting from this is: mobility is aided by having an endpoint
identifier.  To Scott's question, it need not be in the network layer.  It
can also exist purely in a session layer, but some identifier is necessary
so that there can be some continuity of correspondence.  

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 27 Mar 2008 16:35:38 -0400

> so that there can be some continuity of correspondence.  

Yup.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Mar 2008 13:22:46 +1300

> so that there can be some continuity of correspondence.  

There was a good reason, I think, why the OSI model included a
recursive approach to namespaces - NSAP addresses were what we
tended to focus on during the IPng debate, but OSI had LSAP addresses
in the link layer, TSAP addresses in the transport layer and SSAP
addresses in the session layer, iirc. By breaking the integrity of
our "NSAP" layer with NATs etc., we've made it very obvious that
we don't have TSAP addresses.

I'm not sure I see a backwards-compatible fix for this lack.

    Brian

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 28 Mar 2008 06:01:40 -0700

Earlier, Tony Li wrote:
% At the risk of simply summarizing what Pekka and others have said, the key
% point that I'm getting from this is: mobility is aided by having an endpoint
% identifier.  To Scott's question, it need not be in the network layer.  It
% can also exist purely in a session layer, but some identifier is necessary
% so that there can be some continuity of correspondence.

Similarly, such a mechanism can also help enable both node multi-homing
and site multi-homing, for roughly the same reasons.

(I don't think this is a shock to anyone, since this likely was in the minds
of the folks at the IAB Workshop that started this group on its current path.)

Ran