[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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.

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
http://datatracker.ietf.org/drafts/draft-nikander-ram-generix-proxying/

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.

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.

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


--
to unsubscribe send a message to rrg-request@psg.com 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