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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
