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

[Caitlin Bestler]

Fab Tillier wrote:
>> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
>> 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.