[AFS3-std] draft-tkeiser-rxrpc-sec-clear and the node identifier problem

[Tom Keiser]

Hi,

As some of you may recall, draft-tkeiser-rxrpc-sec-clear was written
to address the problem of Rx being transparent to upper-layer node
identifiers--if an Rx service receives a datagram with
RX_CLIENT_INITIATED asserted, it will transparently create a new rx
connection, and potentially establish a security context.  As a
consequence of the transparency with which new contexts are
established, our upper-layer wire protocol is open to race conditions
related to network layer address changes (which can lead to, e.g., a
loss of cache coherence, divergence in the case of shadow clones,
etc.).  In Edinburgh, we discussed the concept of pushing the
responsibility for establishing peer identifiers into the security
object layer, eventually leading to draft-tkeiser-rxrpc-sec-clear.
Obviously, rxrpc-sec-clear--as it currently stands--will only solve
the problem for rxnull connections...

One thing I've been thinking about is turning rxrpc-sec-clear into a
shim layer between Rx and any arbitrary security object--by placing a
sub-securityIndex field in the rxClear header.  This would allow us to
solve the address renumbering race condition problem generally,
without having to duplicate effort in each security class.  However,
my one concern is that this would not be entirely transparent: the
pseudoheader for each sec class would (ideally) need to be modified to
conditionally include the rxClear node identifier assertions in order
to be fully attack-proof...  What do people think of such a proposal?

Cheers,

-Tom