[openib-general] Semantics of transport neutral connection establishment (was Re: [swg] Re: private data...)

[Tom Tucker]

I think this is a useful discussion, however, I would point out that
some of the information being exchanged doesn't have to be in the
private data. It could be exchanged in an untagged send/recv after the
connection is established; which has the benefit of allowing the
application to use an arbitrarily large chunk of data to authenticate
and authorize the remote peer instead of trying to boil the ocean in 64B
of data.

It might be better to only solve the core problem ... which I think is
identifying the service and QP configuration. 

On Thu, 2005-10-20 at 14:58 -0700, Caitlin Bestler wrote:
> I believe a review of what the implementer of a transport neutral
> daemon for an RDMA protocol would be expecting from a Connection
> Management service:
> 
> -- It expects that it can listen for connection requests on a specific
>    16-bit port number (with traditional TCP port number semantics) on
>    either a specific IP Address or for all IP Addresses associated with
>    the network device.

I would expand this to say "...or on all interfaces that have an IP
address". From my reading, it seems to me that the current CMA does
this. 

> -- It will receive connection requests that were initiated by active peers
>    that wish to establish a reliable connection for the purpose of 
>    exchanging RDMA messges.
> 
>    This Connection Request will identify:
> 	1) The remote IP Address of the active peer.
>  This will be
> authenticated
>          in the sense that the address is known to have more meaning than 
>          just being a value made up by a remote user-mode peer. If it is a
> lie
>          then privileged software is complicit in the lie. The address may be
>          even more authenticated than that.

Are you saying that it should not be possible for a user mode peer to
masquerade as another host? If this is what you're saying, then I don't
think it is any more secure done in the kernel than in user mode because
the remote peer has no way of knowing where the data was prepared. 

I think that if authentication is the purpose of the remote address,
don't bother. If the active peer needs to be authenticated, do it after
connection establishment when you can exchange signatures of sufficient
size to be useful. 

Am I missing something here?

> 	2) The destination IP address that the active peer requested. That
> is, if
>          the network device supports multiple addresses concurrently (as with
> a
>          web farm) the connection request will identify *which* address was
>          specified by the remote active peer.

... and port. I agree this is needed because it is part of the "local
service signature" aka service id aka port number/ip address"

> 	3) Private Data supplied by the remote peer to establish its
> identity,

IMHO, private data is useless (or at least insecure) for this purpose
for the reasons mentioned above.

>          the required characteristics of the desired connection and/or other
>          application specific purposes. The private data is supplied prior to
> 	   connection establishment specifically to enable
> selection/configuration of the RDMA QP. 

I agree that this is a useful purpose for private data.


> Note that on a transport neutral basis the passive
> side
> 	   application cannot assume that the QP is fully configured to match
> credit
> 	   requirements of the remote peer -- it must configure QP capacities
> itself.

> -- It will NOT receive connection requests from remote peers seeking to
> connect
>    with similar services based upon streaming socket semantics (SDP or plain
> TCP).

What specifically are you saying here? That the app won't see the
connect request until after an MPA Start Request has been received?

> 
> -- If it so chooses, it may accept the connection request by supplying a
> compatibly
>    configured RDMA QP and response private data.
> -- If it so chooses, it may reject the conneciton request. 

> Many of these requirements point to why the additional data is needed, and
> why taking
> the first N bytes of the existing private data is requried.
> 
> The key requirement that I belive requires that "65th bit" is that a client
> seeking
> a streaming mode daemon cannot initiate a connection with an RDMA mode daemon
> and 
> start mis-exchanging data.

Are you referring to the MPA Start Key thingy again? I don't think the
IB guys don't have this issue.

> 
> If anyone cares to google you can find out that I had a low opinion of the
> value
> of this requirement when it was discussed in the IETF RDDP WG.  Well,
> actually it
> wasn't discussed, it was imposed by fiat by the Transport Area directors.
> 
> But despite my low opinion of it, it is part of IP based RDMA connection
> establishment.
> And in the interest of transport neutrality an InfiniBand option to emulate
> IP based
> connection establishment should emulate it as well.
> 

erf. 

> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general