[caitlin]
Comments inline
[/caitlin]
-----Original Message-----
From: Tom Tucker [mailto:[EMAIL PROTECTED]
Sent: Thu 10/20/2005 9:26 PM
To: Caitlin Bestler
Cc: Sean Hefty; Fab Tillier; [EMAIL PROTECTED]; [email protected]
Subject: Re: [openib-general] Semantics of transport neutral connection
establishment (was Re: [swg] Re: private data...)
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 beauthenticated
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?
[caitlin]
I'm merely noting what a TCP daemon is able to assume today as
part of IP connection setup. The remote IP address supplied may
be heavily authenticated (the local network actively prevents IP
spoofing by checking routes, etc.) or next to worthless (the only
guarantee si that the forger had root access on some machine).
Regardless of whether this level of authentication is advisable, it
is *exactly* the assumption that many servers make today. This
includes many NFS configurations. When the network is isolated
from external connections, and the network administrator is
confident that they control "root" for all machines within the
local network this can be a signifigant level of defense. Within
a corporate intranet, for example, this may be the mechanism
to ensure that marketing does not examine internla engineering
documents. I wouldn't recommend it for protecting HR files, but
it can be quite adequate for many purposes.
More importantly, if this guarantee is not provided then an
explicit warning should be made. For example, unless the
CM header itself is mariked as having IP data in it there is no
way to know that a user mode application simply hasn't made
up an IP address and submitted as part of a normal CM requests
private data.
[/caitlin]
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"
[caitlin]
But the port was implicit in the listen. There is no need for it to
be part of the Connection Request reported to the listener. If there
is a desire to conserve Service IDs then the wire protocol could certainly
include the TCP port in the CM Private Data. But that would be transparent
to the application.
The transparency to the applicaion is my concern. I'll confess to not
seeing any great need to avoid allocating 64K Service IDs out of a
64-bit range -- but that's an issue for the IB developers to work out.
[/caitlin]
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.
[caitlin]
Agreed. This is why private data exists. Application developers
SHOULD use it only for this purpose, and use Send/Recv to exchange
other information.
But the problem is once you label it "private data" the application
developers tend to think of it as their data that they can use anyway
they see fit.
[/caitlin]
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?
[caitlin]
Correct, it is not an IP-ssemantics RDMA Connection Request until
there is no doubt that it is.
Over iWarp/MPA that is established by a valid MPA Request frame.
Over iWARP/SCTP it is established by an association parameter.
For IP-Address-based IB CM that implies that we have to know that
the Private Data actually is in the IP-Address bearing format.
If a stray TCP client who has no idea that they are connecting to an
RDMA daemon initiates a TCP connection that connection will be
handled strictly by the iWARP CM and never reported as an iWARP
connection request to the Consumer.
Similarly, if a stray IB client that has no idea what these "IP semantics"
options are about attempts to connect to a Service that wants the
IP-format CM Private Data the connection request should not be
reported to the Consumer. Especially not with garbled private data
and addressign data taken from the intended private data.
That would be a change in the smenatics for a transport neutral
daemon. It is not responsible for figuring out if the client really
meant to connect with it. Sorting out those who do not know how
to speak the relevant Connection Establishment protocol should
remain a responsibiloity of the Connection Manager (for whatever
connection establishment protocol is in use) and not shifted to
the listener.
[/caitlin]
-- 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.
[caitlin]
They do. But it's not distinquishing a plain TCP client from an iWARP
client. It's distinquishing a Connection Request from a client who wants
an IP semantics connection from one who is using the base CM protocol.
[/caintlin]
