> From: Caitlin Bestler [mailto:[EMAIL PROTECTED] > Sent: Friday, November 11, 2005 9:57 AM > > 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.
Do we need the remote side to vouch for that portion of the private data? The recipient of a CM REQ can validate fully that the GIDs in the path record match the IP addresses. That was the whole point of this proposal - eliminate the need to do some reverse lookup of GID to IP based on the source GID in the path record. With the source IP provided in the private data, the recipient of the CM REQ can do a forward lookup of that IP address and validate that the GID returned matches the one in the CM REQ path. Thus, all address translation can use forward lookups and we eliminate the flaws of the reverse lookup schemes that are currently in use. It doesn't matter one bit if the CM REQ private data was formatted by a privileged entity or not - garbage in the private data can be detected by the receiving entity, even one that sits above the IB CM. - Fab _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
