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

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Scott,

> > > > [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.
>
> 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]

> 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.)

I agree (to an extent) [3].

> 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.

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.



--
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