[openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Caitlin Bestler
caitlinb at broadcom.com
Tue Oct 25 10:03:11 PDT 2005
> -----Original Message-----
> From: Sean Hefty [mailto:mshefty at ichips.intel.com]
> Sent: Tuesday, October 25, 2005 9:56 AM
> To: Caitlin Bestler
> Cc: Kanevsky, Arkady; dat-discussions at yahoogroups.com;
> 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:
> > I believe it requires a CM protocol version change, or a
> "IP Address
> > Header present" bit.
> >
> > Basically, userspace consumers can supply *any* 72 bytes of private
> > data currently.
> > To maintain backwards compatability you need an authenticator that
> > says "this IP header data vouched for by privileged
> components on this
> > end", and that authenticator cannot be within the private data.
>
> I believe that the solution is keep the CM protocol as is.
> The CM private data should be completely controlled by the
> service. The IB CM does not care if an IP address is in the
> private data or not.
>
> My reading of the proposal is that it defines a private data
> format that a particular service may or may not use.
>
Is that because you do not agree that there is a problem?
Or is it that you think the gap betweeen this and existing IP
connection semantics is small enough that it is better to cover
it with a disclosure than by changing the CM protocol?
How would advise an application that uses the remote address
to check an Access Control List (such as an NFS daemon) to
treat this data?
On an IP network the remote IP Address/port was vouched for
by the remote kernel at the minimum, and MAY have been authenticated
by each routing element along the way. Private data supplied through
the existing CM protocol has neither of those safeguards.
More information about the general
mailing list