[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