[openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model

[Caitlin Bestler]

> -----Original Message-----
> From: Sean Hefty [mailto:mshefty at ichips.intel.com] 
> Sent: Tuesday, October 25, 2005 11:21 AM
> To: Caitlin Bestler
> Cc: Kanevsky, Arkady; openib-general at openib.org; swg at infinibandta.org
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 - 
> proposal for socket based connection model
> 
> Caitlin Bestler wrote:
> > What you are proposing is an API that purports to have the 
> semantics 
> > of TCP/IP connection establishment that can be implemented under 
> > non-IP transports such as InfiniBand.
> > 
> > However, as proposed the mapping of this API to InfiniBand 
> does *not* 
> > implement the semantics of TCP/IP connection establishment 
> in that the 
> > remote address presented to the listener has been subject to *no* 
> > authentication.
> > 
> > That is a change in the API that has an impact on the 
> application. It 
> > is creating a requiremet for the application to validate the remote 
> > identity greater than it would face for TCP/IP connection 
> > establishment.
> 
> What API proposal are you referring to?
> 
> If you're referring to the CMA, there's only a kernel 
> (privileged) component in existence.  It sets the IP address 
> in the private data.  What is the issue that you're referring to?
> 
> - Sean
> 

The remote peer will be able to use an existing CM to send a 
forged IP address. There is nothing the receiving CMA, or consumer
(no matter how privileged) can do to detect this without the
cooperation of privileged components on the remote end.

They cannot know that the cooperation they are receiving
from the remote end is from a privileged entity unless it
comes from a privileged QP and is not part of the existing
pass-through data.

And playing the "I'm only in kernel" ostrich game doesn't help.
Any connection establishment protocol has to make sense from
both user and kernel modes and needs to be symmetric. But it
needs to include clear controls on who is trusted to provide
what information, and what information MUST come from a privileged
entity.

A source IP address that can come from a non-privileged entity
is NOT consistent with IP network connection establishment semantics.