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

[Renato Recio]

The CM cannot get a message from a non-priviliged requestor, because a
non-privilited requestor cannot insert the priviliged Q_Key into the
packet.

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685



                                                                                                                                   
                      "Caitlin Bestler"                                                                                            
                      <caitlinb at broadco        To:       "Sean Hefty" <mshefty at ichips.intel.com>, "Kanevsky, Arkady"               
                      m.com>                    <Arkady.Kanevsky at netapp.com>                                                       
                                               cc:       swg at infinibandta.org, openib-general at openib.org,                          
                      11/11/2005 11:56          dat-discussions at yahoogroups.com                                                    
                      AM                       Subject:  [swg] RE: [openib-general] RE: [dat-discussions] socket based             
                                                connectionmodel for IB proposal - round 3                                          
                                                                                                                                   
                                                                                                                                   




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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/bc2ccc20/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/bc2ccc20/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/bc2ccc20/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic25893.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/bc2ccc20/attachment-0002.gif>