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

[Renato Recio]

A current passive side CM will reject the incoming CM REQ, because the
Service ID will not be recognized.

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:       Renato Recio/Austin/IBM at IBMUS                                                     
                      m.com>                   cc:       "Kanevsky, Arkady" <Arkady.Kanevsky at netapp.com>, dat-discussions at yahoogroups.com, 
                                                "Sean Hefty" <mshefty at ichips.intel.com>, openib-general at openib.org, swg at infinibandta.org   
                      11/11/2005 03:12         Subject:  RE: [swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel 
                      PM                        for IB proposal - round 3                                                                  
                                                                                                                                           
                                                                                                                                           






 From: Renato Recio [mailto:recio at us.ibm.com]
 Sent: Friday, November 11, 2005 12:25 PM
 To: Caitlin Bestler
 Cc: Kanevsky, Arkady; dat-discussions at yahoogroups.com; Sean Hefty;
 openib-general at openib.org; swg at infinibandta.org
 Subject: RE: [swg] RE: [openib-general] RE: [dat-discussions] socket based
 connectionmodel for IB proposal - round 3



 Any active side QP can target a passive side CM QP (QP1 or redirected
 QPN). However, due to the use of priviliged Q_Keys, only an active side
 priviliged QP can target the passive side CM QP.

 It seems to me that our proposal of having the Service ID be generated by
 priviliged mode code, having a Service ID associated with RDMA Services
 (e.g. iSER, NFSeR, ...), and having priviliged mode code generate the
 first N bytes of the private data field (i.e. the bytes in question);
 allows the passive side:
       - Transport to validate an incoming CM message was generated by a
       priviliged consumer; and
       - CM to know the Service ID and first N-bytes of the private data
       field were generated by a priviliged consumer.




How does this prevent a non-privileged client running on a remote host with
current
CM software from generating a connection request to the targeted Service ID
with the entire private data coming from the non-privileged consumer.

A current CM does not know that the Service ID requires it to
generate/validate
any portion of the private data.

A current CM does not know how to use a later version number or to set a
bit that is currently defined as reserved.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/13bb8e46/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/13bb8e46/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/13bb8e46/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic18741.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/13bb8e46/attachment-0002.gif>