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

["Tony Li" <tony.li@tony.li>]

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


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