At 10:30 AM 6/24/2005, Roland Dreier wrote:
Thomas> As
I said - I am not attached to ATS. I would welcome an
Thomas> alternative.
Sure, understood. I'm suggesting a slight tweak to the IB wire
protocol. I don't think there's a difference in the security
provided, and carrying the peer a
The Sun implementation uses a Service ID from the "Local OS
Administrative" range when installing an entry in the SA. So, the first
byte should be 0x2 in the ServiceID component in the SA record. The
Service Name in the SA record contained the IP address with the NFS port
number appended at the
At 05:34 PM 6/27/2005, Roland Dreier wrote:
>I'm not sure I understand this. At best, ATS can give you back a list
>of IPs. How do you decide which one to check against the exports?
Any or all of them. Exports is a fairly simple access list, and membership
by the client is all that's required. I
Itamar> But the ATS will not solve the problem of "many to one".
Itamar> What will the nfs module will do if the the result from
Itamar> the ATS will be a list of "IP's" which only one of them is
Itamar> has permission to the nfs ? ATS cant tell you who is the
Itamar> source IP
At 03:10 AM 6/26/2005, Itamar Rabenstein wrote:
>But the ATS will not solve the problem of "many to one".
>What will the nfs module will do if the the result from the ATS will be
>a list of "IP's" which only one of them is has permission to the nfs ?
>ATS cant tell you who is the source IP.
The N
> On the other hand, placing a mandatory content in the CM exchange
> brings in a whole different raft of interoperability
> questions, as James
> mentioned earlier. For better or for worse, the ATS approach is easily
> administered and does not impact any protocol layers outside of its
> own. I t
On Fri, 2005-06-24 at 15:14, Talpey, Thomas wrote:
> At 02:27 PM 6/24/2005, Hal Rosenstock wrote:
> >On Fri, 2005-06-24 at 13:51, Talpey, Thomas wrote:
> >> mentioned earlier. For better or for worse, the ATS approach is easily
> >> administered and does not impact any protocol layers outside of it
At 02:27 PM 6/24/2005, Hal Rosenstock wrote:
>On Fri, 2005-06-24 at 13:51, Talpey, Thomas wrote:
>> mentioned earlier. For better or for worse, the ATS approach is easily
>> administered and does not impact any protocol layers outside of its
>> own. I think of it as ARP for IB.
>
>reverse ARP for I
On Fri, 2005-06-24 at 13:51, Talpey, Thomas wrote:
> On the other hand, placing a mandatory content in the CM exchange
> brings in a whole different raft of interoperability questions, as James
> mentioned earlier. For better or for worse, the ATS approach is easily
> administered and does not impa
At 01:30 PM 6/24/2005, Roland Dreier wrote:
>Thomas> But in the absence of one, I like what we have. Also, I do
>Thomas> not want to saddle the NFS/RDMA transport with carrying an
>Thomas> IP address purely for the benefit of a missing transport
>Thomas> facility. After all NFS/RDMA
Roland> Right, but at least for now the SA has no way of checking
Roland> the IP address in a request to decide whether or not it
Roland> should allow creating an ATS record.
Hal> In fact, the SA does not know it is an IP address in the
Hal> ServiceData of the ServiceRecord.
R
On the subject of NFS/RDMA, what is the IB ServiceID space that is used?
If I recall correctly, I have seen simply the value 2049 (i.e. the
standard TCP/UDP port number) used in some implementations (i.e. 00 00
00 00 00 00 20 49). Is there a mapping onto an IB ServiceID defined?
We aren
Thomas> As I said - I am not attached to ATS. I would welcome an
Thomas> alternative.
Sure, understood. I'm suggesting a slight tweak to the IB wire
protocol. I don't think there's a difference in the security
provided, and carrying the peer address in the CM private data avoids
a lot of
On Fri, 2005-06-24 at 13:22, Roland Dreier wrote:
> Hal> The first level of IB trust in terms of the SA (authenticaing
> Hal> the requestor) is restrictions based on access
> Hal> (partitioning). This is true for a number of SA attributes
> Hal> which is more than (just) ServiceReco
At 01:22 PM 6/24/2005, Roland Dreier wrote:
>Hal> But we do trust the kernel, right ?
>
>No, an NFS server can't trust anything coming from a remote client.
Well, the server can't trust untrusted information coming from the
client. NFS has many forms of strong authentication. But many,
many us
Thomas> We aren't currently using the portmapper to discover the
Thomas> serviceid that the NFS/RDMA server is listening on. Brent
Thomas> Callaghan chose serviceid 2049 as a convenience in Sun's
Thomas> first implementation, and so far it has stuck.
Ugh, according to the IBA spec
At 12:42 PM 6/24/2005, Roland Dreier wrote:
>Thomas> But that's totally and completely insecure. The goal of
>Thomas> /etc/exports is to place at least part of the client
>Thomas> authentication in the network rather than the supplied
>Thomas> credentials. NFS has quite enough of a
Hal> The first level of IB trust in terms of the SA (authenticaing
Hal> the requestor) is restrictions based on access
Hal> (partitioning). This is true for a number of SA attributes
Hal> which is more than (just) ServiceRecords.
Right, but at least for now the SA has no way of che
At 01:02 PM 6/24/2005, Jay Rosser wrote:
>On the subject of NFS/RDMA, what is the IB ServiceID space that is used?
>If I recall correctly, I have seen simply the value 2049 (i.e. the
>standard TCP/UDP port number) used in some implementations (i.e. 00 00
>00 00 00 00 20 49). Is there a mapping o
On Fri, 2005-06-24 at 12:42, Roland Dreier wrote:
> Thomas> But that's totally and completely insecure. The goal of
> Thomas> /etc/exports is to place at least part of the client
> Thomas> authentication in the network rather than the supplied
> Thomas> credentials. NFS has quite en
The presumption behind authenticating by remote address is
that the local subnet is sufficiently administered so as to
prevent address spoofing.
That would require firewalls, configured switches and other
techniques for an IP network, and for IB ensuring that the
IB subnet administration is not s
On the subject of NFS/RDMA, what is the IB ServiceID space that is used?
If I recall correctly, I have seen simply the value 2049 (i.e. the
standard TCP/UDP port number) used in some implementations (i.e. 00 00
00 00 00 00 20 49). Is there a mapping onto an IB ServiceID defined?
Thanks,
Jay
> Why do you say ATS only works for IPv4 and doesn't support multiple IP
> addresses on a single interface ? It certainly does the later. Both IPv4
> and v6 addresses are accomodated in the ATS SR definition. Any IPv4ness
> of the some ATS APIs (and the underlying implementation) need to be
> enhan
Thomas> But that's totally and completely insecure. The goal of
Thomas> /etc/exports is to place at least part of the client
Thomas> authentication in the network rather than the supplied
Thomas> credentials. NFS has quite enough of a history with
Thomas> AUTH_SYS to prove the i
At 12:19 PM 6/24/2005, Roland Dreier wrote:
>It seems far preferable to me to just define the wire protocol of
>NFS/RDMA for IB such that a client passes its IP address as part of
>the connection request. This scheme was used for SDP to avoid
>precisely the complications that we're discussing now.
On Fri, 2005-06-24 at 12:19, Roland Dreier wrote:
> Sure, I understand why NFS/RDMA wants the peer address. However,
> forcing this into kDAPL and then making kDAPL go through contortions
> to provide it seems like the wrong way around. We end up with gross
> hacks like ATS, which only works for
Thomas> Yes, it's weak, but it's needed. A good example is the NFS
Thomas> server's "exports" function. For the last 20 or so years,
Thomas> NFS servers have a table which assigns access rights to
Thomas> filesystems by IP address, for example restricting access,
Thomas> making
On Fri, 2005-06-24 at 11:58, Roland Dreier wrote:
> Hal> I think this part is simpler than this. Aren't the
> Hal> primary/alternate GIDs in the CM REQ ?
>
> Yes, but the remote peer could lie, right?
So there needs to be one more SA lookup to validate that the GID is
associated with the
Hal> I think this part is simpler than this. Aren't the
Hal> primary/alternate GIDs in the CM REQ ?
Yes, but the remote peer could lie, right?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/ope
At 01:31 PM 6/23/2005, Roland Dreier wrote:
>James> kDAPL uses this feature to provide the passive side of a
>James> connection with the IP address of the remote peer. kDAPL
>James> consumers can use this information as a weak authentication
>James> mechanism.
>
>This seems so weak
On Thu, 23 Jun 2005, Fab Tillier wrote:
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 23, 2005 10:32 AM
James> Perhaps a bit of motivation of how the GID->IP service can
James> be used is in order.
James> kDAPL uses this feature to provide the passive side of
On Thu, 23 Jun 2005, Roland Dreier wrote:
James> Perhaps a bit of motivation of how the GID->IP service can
James> be used is in order.
James> kDAPL uses this feature to provide the passive side of a
James> connection with the IP address of the remote peer. kDAPL
James> consume
On Thu, 2005-06-23 at 13:31, Roland Dreier wrote:
> James> Perhaps a bit of motivation of how the GID->IP service can
> James> be used is in order.
>
> James> kDAPL uses this feature to provide the passive side of a
> James> connection with the IP address of the remote peer. kDAPL
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 23, 2005 10:32 AM
>
> James> Perhaps a bit of motivation of how the GID->IP service can
> James> be used is in order.
>
> James> kDAPL uses this feature to provide the passive side of a
> James> connection with
James> Perhaps a bit of motivation of how the GID->IP service can
James> be used is in order.
James> kDAPL uses this feature to provide the passive side of a
James> connection with the IP address of the remote peer. kDAPL
James> consumers can use this information as a weak auth
On Thu, 23 Jun 2005, Hal Rosenstock wrote:
On Thu, 2005-06-23 at 11:47, Roland Dreier wrote:
James> The IBAT API provides the two key services needed by kDAPL:
James> the ability to obtain a route based on an IP address and
James> the ability to map a GID to an IP address.
Ja
On Thu, 2005-06-23 at 11:47, Roland Dreier wrote:
> James> The IBAT API provides the two key services needed by kDAPL:
> James> the ability to obtain a route based on an IP address and
> James> the ability to map a GID to an IP address.
>
> James> Is there agreement that an IB addr
James> The IBAT API provides the two key services needed by kDAPL:
James> the ability to obtain a route based on an IP address and
James> the ability to map a GID to an IP address.
James> Is there agreement that an IB address translation service
James> must provide these two se
On Tue, 21 Jun 2005, Hal Rosenstock wrote:
On Mon, 2005-06-20 at 23:40, Roland Dreier wrote:
There was some discussion a while ago about an "IB address
translation" service proposed by the Voltaire crew, which would
encapsulate some of this. However, we didn't make much progress
towards a goo
Hi again Kevin,
I'd like to go back to your original query to make sure I understand
things.
On Mon, 2005-06-20 at 22:23, Kevin Reilly wrote:
> Maybe somebody could help me understand the proper way to map between an IP
> address assigned to a port to the
> "device name" and "port number" in the
cc
> AMopenib-general@openib.org
> Subject
> Re
openib-general@openib.org
Subject
Re: [openib-general] mapping
between IP address and
On Tue, 2005-06-21 at 11:44, Caitlin Bestler wrote:
> Expanding slightly on Hal's response, the correct method to correlate
> an *IP* address with a device is to consult the *IP* routing tables.
> While there are exceptions where you want to control the local
> address,
With IBAT there is a way t
Expanding slightly on Hal's response, the correct method to correlate
an *IP* address with a device is to consult the *IP* routing tables.
While there are exceptions where you want to control the local
address, it is far more common that you need to reach a remote
address (or be reachable from a r
On Tue, 2005-06-21 at 01:14, Libor Michalek wrote:
> On Mon, Jun 20, 2005 at 08:40:47PM -0700, Roland Dreier wrote:
> > Kevin> Maybe somebody could help me understand the proper way to
> > Kevin> map between an IP address assigned to a port to the "device
> > Kevin> name" and "port numb
On Mon, 2005-06-20 at 23:40, Roland Dreier wrote:
> There was some discussion a while ago about an "IB address
> translation" service proposed by the Voltaire crew, which would
> encapsulate some of this. However, we didn't make much progress
> towards a good API design, and the discussion fizzle
Hi Kevin,
On Mon, 2005-06-20 at 22:23, Kevin Reilly wrote:
> Maybe somebody could help me understand the proper way to map between an IP
> address assigned to a port to the
> "device name" and "port number" in the gen2 architecture. If I have an IP
> address can I map it to a name that i get ba
On Mon, Jun 20, 2005 at 08:40:47PM -0700, Roland Dreier wrote:
> Kevin> Maybe somebody could help me understand the proper way to
> Kevin> map between an IP address assigned to a port to the "device
> Kevin> name" and "port number" in the gen2 architecture. If I
> Kevin> have an IP
Kevin> Maybe somebody could help me understand the proper way to
Kevin> map between an IP address assigned to a port to the "device
Kevin> name" and "port number" in the gen2 architecture. If I
Kevin> have an IP address can I map it to a name that i get back
Kevin> from ibv_get
Maybe somebody could help me understand the proper way to map between an IP
address assigned to a port to the
"device name" and "port number" in the gen2 architecture. If I have an IP
address can I map it to a name that i get back
from ibv_get_device_name() or pass to ibv_open_device().
50 matches
Mail list logo
