[openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3

[Caitlin Bestler]

Sean Hefty wrote in response to Arkady Kanevsky:

> 
> What's this proposal defines is basically a 65th bit for the
> service ID.  If the new 65 bit SID is:
> 
> 1 <anything>	- private data has this format
> 0 <anything>	- private data format is unknown
> 
> Why do we need this 65th bit?
> 

Because current software can set any of the 64 bits.
There is no assurance that any bit within the current 64
being set means that privileged software on the remote
side is vouching for the standardized portion of the
private data.

An NFS daemon today knows that the remote IP address of
an established connection is consistent with the local
routing configured at the privileged layer in at least
two locations (the local machine and the remote peer).

Because an IP address is not used for routing we are
already losing some of that. Having *neither* end be
validated by the network stack is a serious change in
the semantics of a connection request. Daemons frqeuently
use the remote IP address to validate at least some clients
as being "local" and hence trusted. On an IP network this
is amazingly effective if combined with ingress filtering.
But even if there is no ingress filtering, an established
connection with a local IP address is inherently local.
It is at most single packets, or those outside of a
connection, that are suspect.

Unless there is information in the REQ that cannot be set
by a current CM in response to a non-privileged request
then the Daemon loses this ability of inferrig "neighbor
status" based on the remote IP address. That is simply
no longer "IP compatible" connection establishment.