Fab Tillier wrote: >> From: Caitlin Bestler [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 11, 2005 1:12 PM >> >> 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. > > There is no need to prevent a non-privileged client from > generating connection requests. Where does this requirement > come from? Who cares where the private data comes from as > long as the recipient, whether privileged or not, has a way > of validating that it matches the path record information? > > Specifically, adding the logic in the low level IB CM to > validate the private data will tie the IB CM to address > translation for IPoIB, which I think is better done at a > higher level (like the CMA). > > If a higher level entity is going to be responsible for > validating the private data, the low level IB CM doesn't do > squat with the reserved bit. The low level CM API must now > expose the bit to allow clients to specify it so that REQs > can be routed to them, so that two requests with the same SID > can be distinguished form one another by this reserved bit. > Thus if the bit has to be exposed through the low-level IB CM > it is no more than a 65th bit for a service ID. > By the time the connection request is passed to the application the remote IP address needs to be validated.
I don't care whether the remote CM validated it (and is known to be privileged software) or if the local CM validates it with a reverse lookup. What I do not want is to kick this problem up to the application. If it is kicked up to the application it is no longer TCP-compatible connection setup, because that responsibility does not exist over TCP. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
