[swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3
Caitlin Bestler
caitlinb at broadcom.com
Fri Nov 11 13:12:27 PST 2005
________________________________
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/b2daee2b/attachment.html>
More information about the general
mailing list