<html><body>
<p>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.<br>
<br>
Renato J Recio<br>
Chief Architect, eServer I/O<br>
IBM Distinguished Engineer<br>
Member IBM Academy of Technology<br>
Tel 512-838-3685, T/L 678-3685<br>
<br>
<img src="cid:10__=09BBFA25DFFBCAC98f9e8a93df938@us.ibm.com" width="16" height="16" alt="Inactive hide details for "Caitlin Bestler" <caitlinb@broadcom.com>">"Caitlin Bestler" <caitlinb@broadcom.com><br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:20__=09BBFA25DFFBCAC98f9e8a93df938@us.ibm.com" border="0" height="1" width="72" alt=""><br>
</td><td style="background-image:url(cid:30__=09BBFA25DFFBCAC98f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="1%"><img src="cid:20__=09BBFA25DFFBCAC98f9e8a93df938@us.ibm.com" border="0" height="1" width="225" alt=""><br>
<ul>
<ul>
<ul>
<ul><b><font size="2">"Caitlin Bestler" <caitlinb@broadcom.com></font></b>
<p><font size="2">11/11/2005 11:56 AM</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:20__=09BBFA25DFFBCAC98f9e8a93df938@us.ibm.com" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> To: </font><font size="2">"Sean Hefty" <mshefty@ichips.intel.com>, "Kanevsky, Arkady" <Arkady.Kanevsky@netapp.com></font><br>
<font size="2"> cc: </font><font size="2">swg@infinibandta.org, openib-general@openib.org, dat-discussions@yahoogroups.com</font><br>
<font size="2"> Subject: </font><font size="2">[swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3</font></td></tr>
</table>
<br>
<br>
<font face="Courier New">Sean Hefty wrote in response to Arkady Kanevsky:<br>
<br>
> <br>
> What's this proposal defines is basically a 65th bit for the<br>
> service ID. If the new 65 bit SID is:<br>
> <br>
> 1 <anything> - private data has this format<br>
> 0 <anything> - private data format is unknown<br>
> <br>
> Why do we need this 65th bit?<br>
> <br>
<br>
Because current software can set any of the 64 bits.<br>
There is no assurance that any bit within the current 64<br>
being set means that privileged software on the remote<br>
side is vouching for the standardized portion of the<br>
private data.<br>
<br>
An NFS daemon today knows that the remote IP address of<br>
an established connection is consistent with the local<br>
routing configured at the privileged layer in at least<br>
two locations (the local machine and the remote peer).<br>
<br>
Because an IP address is not used for routing we are<br>
already losing some of that. Having *neither* end be<br>
validated by the network stack is a serious change in<br>
the semantics of a connection request. Daemons frqeuently<br>
use the remote IP address to validate at least some clients<br>
as being "local" and hence trusted. On an IP network this<br>
is amazingly effective if combined with ingress filtering.<br>
But even if there is no ingress filtering, an established<br>
connection with a local IP address is inherently local.<br>
It is at most single packets, or those outside of a<br>
connection, that are suspect.<br>
<br>
Unless there is information in the REQ that cannot be set<br>
by a current CM in response to a non-privileged request<br>
then the Daemon loses this ability of inferrig "neighbor<br>
status" based on the remote IP address. That is simply<br>
no longer "IP compatible" connection establishment.<br>
<br>
</font>
</body></html>