RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 11:21 AM > To: Caitlin Bestler > Cc: Kanevsky, Arkady; openib-general@openib.org; [EMAIL PROTECTED] > 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. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Tom Tucker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 11:13 AM > To: Caitlin Bestler > Cc: Sean Hefty; Kanevsky, Arkady; [EMAIL PROTECTED]; DAT > Collaborative; openib-general@openib.org > Subject: RE: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > On Tue, 2005-10-25 at 10:51 -0700, Caitlin Bestler wrote: > > > > > > > > > > I believe that the assurances you are talking about are > peculiar to > > > an implementation, not to the network. > > > > > > > I disagree. Anytime you send an IP datagram on an IP > network you are > > expected to provide an authentic source address. Any intermediate > > network device MAY enforce that rule and drop packets with invalid > > source addresses. > > > > I don't see anything in the protocol specs (RFC 791, RFC 793, > ...) that talks about this, so we just have to agree to disagree. :-) > Joe Touch's current draft on spoofing prevention covers this well in Section 3.2 (draft-ietf-tcpm-tcp-antispoof-02). IP networks can prevent address spoofing at the network layer using IPSec or by having border routers/filters validate the source address of incoming packets against routing rules. The latter is covered in RFC 2827 "Ingress Filtering for Multihomed Networks" and RFC 2267 "Network Ingress Ingress Filtering: Defeating Denial of Service Attacks which employ IP Address Spoofing" And more generally, in a TCP network a non-privileged client is NOT allowed to bind to any address and is NOT allowed to send raw Ethernet to bypass the host stack. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
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 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 11:10 AM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > Kanevsky, Arkady wrote: > > It is APIs not ULPs that are concern. > > Yes - and an application that wants to use IP addressing > instead of IB addressing should use a different API than that > of the IB CM. Trying to define the IB CM to use anybody's > favorite transport/network address is the wrong solution to > the problem. That is a service level issue best left to the > service that's trying to perform the mapping. > 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. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
On Tue, 2005-10-25 at 10:51 -0700, Caitlin Bestler wrote: > > > > > > I believe that the assurances you are talking about are > > peculiar to an implementation, not to the network. > > > > I disagree. Anytime you send an IP datagram on an IP network > you are expected to provide an authentic source address. Any > intermediate network device MAY enforce that rule and drop > packets with invalid source addresses. > I don't see anything in the protocol specs (RFC 791, RFC 793, ...) that talks about this, so we just have to agree to disagree. :-) > IP Addresses stored in private data, by contrast, are guaranteed > to pass all middleboxes unmolested without review of validation. > This is not a spoofer taking advantage of a lazy network admin, > this is a spoofer being given a "get out of jail free" card that > says the network admin is not even allowed to do spot checks. > > > The CMA is what is preparing the private data header, not the > > app. WRT a IB CM app, it could very easily pretend to be a > > "CMA App" and build it's own private data that spoofed the > > address. How would the local CM know that it is supposed to > > verify this? Where is the service id/private data format > > mapping database? > > > > In short, I think we are mixing many different things together here. > > > > > > For the very same reasons that a userspace consumer is not allowed > to pretend to be the CM itself, it should not be allowed to just > make up Source IP Addresses. If it's going to lie it needs to be > a privileged liar. > > Preserving the existing CM infrastructure is fine, but not if it > forces us to take something that should be authenticated by privileged > software and simply trust that userspace code will fill it in correctly. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Kanevsky, Arkady wrote: It is APIs not ULPs that are concern. Yes - and an application that wants to use IP addressing instead of IB addressing should use a different API than that of the IB CM. Trying to define the IB CM to use anybody's favorite transport/network address is the wrong solution to the problem. That is a service level issue best left to the service that's trying to perform the mapping. Each ULP can define its own protocol. Each ULP does define its own protocol - connection or otherwise. SDP cannot talk to IPoIB which cannot talk to SRP. If ULP uses API, it does the parsing. APIs are merely an interface. What needs to be defined is a service that can do the parsing. For Linux, the API to that service should be defined using the standard open source method. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
It is APIs not ULPs that are concern. Each ULP can define its own protocol. But APIs can not. But defining a protocol for each ULP is also bad. This proposal defines it for all ULPs. If ULP uses API, it does the parsing. If ULP uses verbs it can do the parsing and encoding itself. But in the later case it will have to have a different ULP CM for each transport. Bad idea. Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 > -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 1:52 PM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > > Kanevsky, Arkady wrote: > > Sean, > > The reason IBTA is interested to address IP address issue > > is because of multiple UPLs and APIs want to support > > socket based connection model. Sure each one of them > > can define its own protocol (for private data). > > But this will not ensure interoperability. > > There's no interoperability between different ULPs anyway. > Each does define its > own protocol. Trying to standardize part of the CM REQ > private data doesn't > help in this regard. > > - Sean > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> > I believe that the assurances you are talking about are > peculiar to an implementation, not to the network. > I disagree. Anytime you send an IP datagram on an IP network you are expected to provide an authentic source address. Any intermediate network device MAY enforce that rule and drop packets with invalid source addresses. IP Addresses stored in private data, by contrast, are guaranteed to pass all middleboxes unmolested without review of validation. This is not a spoofer taking advantage of a lazy network admin, this is a spoofer being given a "get out of jail free" card that says the network admin is not even allowed to do spot checks. > The CMA is what is preparing the private data header, not the > app. WRT a IB CM app, it could very easily pretend to be a > "CMA App" and build it's own private data that spoofed the > address. How would the local CM know that it is supposed to > verify this? Where is the service id/private data format > mapping database? > > In short, I think we are mixing many different things together here. > > For the very same reasons that a userspace consumer is not allowed to pretend to be the CM itself, it should not be allowed to just make up Source IP Addresses. If it's going to lie it needs to be a privileged liar. Preserving the existing CM infrastructure is fine, but not if it forces us to take something that should be authenticated by privileged software and simply trust that userspace code will fill it in correctly. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Kanevsky, Arkady wrote: Sean, The reason IBTA is interested to address IP address issue is because of multiple UPLs and APIs want to support socket based connection model. Sure each one of them can define its own protocol (for private data). But this will not ensure interoperability. There's no interoperability between different ULPs anyway. Each does define its own protocol. Trying to standardize part of the CM REQ private data doesn't help in this regard. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Sean, The reason IBTA is interested to address IP address issue is because of multiple UPLs and APIs want to support socket based connection model. Sure each one of them can define its own protocol (for private data). But this will not ensure interoperability. Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 > -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 1:34 PM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > > Kanevsky, Arkady wrote: > > Think of a single API that supports iWARP and IB (transport > > independent API). > > The CMA implements this today and did not require any changes > to the IB CM. > > > To a connection listener it provides the IP 5-tuple + private data. > > For IB it means that CM parses REQ and extracts IP 5-tuple > as separate > > fields from private data. > > Why push this down into the CM? The CM should operate on IB > addresses, not IP > addresses. The mapping of IP addresses to IB addresses is > done at a higher level. > > > Listener does not parse the private data encoding of the proposal. > > The listener is the one who cares about the IP addressing. > > - Sean > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
On Tue, 2005-10-25 at 10:21 -0700, Caitlin Bestler wrote: > > > -Original Message- > > From: Sean Hefty [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 25, 2005 10:08 AM > > To: Kanevsky, Arkady > > Cc: Caitlin Bestler; [EMAIL PROTECTED]; > > openib-general@openib.org; [EMAIL PROTECTED] > > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > > proposal for socket based connection model > > > > Kanevsky, Arkady wrote: > > > Correct. > > > But this does bring the question how responder CM knows > > that it need > > > to parse the private data. I suspect this will be done via > > new version > > > of CM. > > > But a suage of some of the CM REQ reserved fields are also possible. > > > Anotherwords the current CM version assumes that CM only > > supports one > > > version and there is no need to support more than 1 version. > > > > The responder knows how to parse the private data based on > > the service ID that they're listening on. This is how it's > > done today, and how it will still need to be done. What is > > the motivation to change it? > > > > What data is beyond the addressing? How does the responder > > know how to interpret that? > > > > I agree, the listener is responsible for knowing what format > the Private Data is supposed to be in. Therefore it knows in > advance what portions of it are relevant to the CM (the IP > address information and/or the ITAPI IRD/ORD pre-header). > So the listen request can specify the required CM parsing. > > But that does not prevent a non-privileged application from > forging the IP address information. These connection requests > are being presented to daemons as though they had the same > degree of authentication as address headers in an IP network > could have. The latter can be quite high when switches and > routers validate source addresses versus arriving ports. I believe that the assurances you are talking about are peculiar to an implementation, not to the network. The CMA is what is preparing the private data header, not the app. WRT a IB CM app, it could very easily pretend to be a "CMA App" and build it's own private data that spoofed the address. How would the local CM know that it is supposed to verify this? Where is the service id/private data format mapping database? In short, I think we are mixing many different things together here. > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Kanevsky, Arkady wrote: Think of a single API that supports iWARP and IB (transport independent API). The CMA implements this today and did not require any changes to the IB CM. To a connection listener it provides the IP 5-tuple + private data. For IB it means that CM parses REQ and extracts IP 5-tuple as separate fields from private data. Why push this down into the CM? The CM should operate on IB addresses, not IP addresses. The mapping of IP addresses to IB addresses is done at a higher level. Listener does not parse the private data encoding of the proposal. The listener is the one who cares about the IP addressing. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Tom Tucker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 10:24 AM > To: Caitlin Bestler > Cc: DAT Collaborative; openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > What does this have to do with the protocol? > It's a whopping big security vulnerability. The application is left with an expectation that the address is more validated than it is. Admittedly even on an IP network it is not perfectly authenticated, but with this protocol the remote address information is far less authenticated and trivially spoofed. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Caitlin Bestler wrote: 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? I would define the problem as: applications want to connect over IB using IP addressing. Defining the CM REQ private data solves is only a small part of the solution (reverse lookup). 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. I think that security is a separate issue outside of this. I have no idea what OS is running on a remote system, let alone how it may have verified an address. That said, the kernel CMA would set this data based on information that it collects. But only users of the CMA would have this additional protection. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Think of a single API that supports iWARP and IB (transport independent API). To a connection listener it provides the IP 5-tuple + private data. For IB it means that CM parses REQ and extracts IP 5-tuple as separate fields from private data. Listener does not parse the private data encoding of the proposal. So CM need to know if it need to encode IP 5-tuple on requestor side and if need to parse on responder side. Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 > -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 1:08 PM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; [EMAIL PROTECTED]; > openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > > Kanevsky, Arkady wrote: > > Correct. > > But this does bring the question how responder CM knows > that it need > > to parse the private data. I suspect this will be done via > new version > > of CM. But a suage of some of the CM REQ reserved fields are also > > possible. Anotherwords the current CM version assumes that CM only > > supports one version and there is no need to support more than 1 > > version. > > The responder knows how to parse the private data based on > the service ID that > they're listening on. This is how it's done today, and how > it will still need > to be done. What is the motivation to change it? > > What data is beyond the addressing? How does the responder > know how to > interpret that? > > - Sean > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
What does this have to do with the protocol? On Tue, 2005-10-25 at 09:35 -0700, Caitlin Bestler wrote: > On an IP network, a non-privileged user is generally not capable of > forging > a source IP address and is typically prevented from using certain > source ports. > > I would propose that the CM [MAY|SHOULD|MUST] enforce that a non- > privileged > user can only use a Source IP Address and Port that they would have > been > able to use following the normal stack path (or what it would have > been in the > case that there is no conventional IP stack associated with this > path). > > So if IPoIB is installed, you would not be able to use any address > that > you would have been blocked from using over IPoIB. Or at least you > would not be guaranteed that you could. > > I think that MUST is the correct level of enforcement, but it needs to > be > clear that the CM and OS *MAY* do this checking and that a userspace > IB application cannot use the IB stack to perform IP spoofing. > > > __ > From: [EMAIL PROTECTED] [mailto:dat- > [EMAIL PROTECTED] On Behalf Of Kanevsky, Arkady > Sent: Tuesday, October 25, 2005 9:00 AM > To: openib-general@openib.org; dat- > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [dat-discussions] round 2 - proposal for socket based > connection model > > > Dear OpenIB, SWG and DAT members, > enclosed is teh second version of the proposal. > There are really 2 proposals that are related. > The first one is encoding IP 5-tuple into REQ private data > with small additional info for versioning and IB capabilities. > The second is just a couple of ideas, not a real proposal, > on maping of IP ports > to IB Service IDs. > > Thanks everybody for tons of feedback and deep discussions. > I appologize if I had missed something. > > Happy reading, > Arkady > > > Arkady Kanevsky email: [EMAIL PROTECTED] > > Network Appliance phone: 781-768-5395 > > 375 Totten Pond Rd. Fax: 781-895-1195 > > Waltham, MA 02451-2010 central phone: 781-768-5300 > > > > > > > > __ > YAHOO! GROUPS LINKS > > 1. Visit your group "dat-discussions" on the web. > > 2. To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > 3. Your use of Yahoo! Groups is subject to the Yahoo! > Terms of Service. > > > __ > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 10:08 AM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; [EMAIL PROTECTED]; > openib-general@openib.org; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > Kanevsky, Arkady wrote: > > Correct. > > But this does bring the question how responder CM knows > that it need > > to parse the private data. I suspect this will be done via > new version > > of CM. > > But a suage of some of the CM REQ reserved fields are also possible. > > Anotherwords the current CM version assumes that CM only > supports one > > version and there is no need to support more than 1 version. > > The responder knows how to parse the private data based on > the service ID that they're listening on. This is how it's > done today, and how it will still need to be done. What is > the motivation to change it? > > What data is beyond the addressing? How does the responder > know how to interpret that? > I agree, the listener is responsible for knowing what format the Private Data is supposed to be in. Therefore it knows in advance what portions of it are relevant to the CM (the IP address information and/or the ITAPI IRD/ORD pre-header). So the listen request can specify the required CM parsing. But that does not prevent a non-privileged application from forging the IP address information. These connection requests are being presented to daemons as though they had the same degree of authentication as address headers in an IP network could have. The latter can be quite high when switches and routers validate source addresses versus arriving ports. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Kanevsky, Arkady wrote: Correct. But this does bring the question how responder CM knows that it need to parse the private data. I suspect this will be done via new version of CM. But a suage of some of the CM REQ reserved fields are also possible. Anotherwords the current CM version assumes that CM only supports one version and there is no need to support more than 1 version. The responder knows how to parse the private data based on the service ID that they're listening on. This is how it's done today, and how it will still need to be done. What is the motivation to change it? What data is beyond the addressing? How does the responder know how to interpret that? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
> -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 9:56 AM > To: Caitlin Bestler > Cc: Kanevsky, Arkady; [EMAIL PROTECTED]; > openib-general@openib.org; [EMAIL PROTECTED] > 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. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Correct. But this does bring the question how responder CM knows that it need to parse the private data. I suspect this will be done via new version of CM. But a suage of some of the CM REQ reserved fields are also possible. Anotherwords the current CM version assumes that CM only supports one version and there is no need to support more than 1 version. This proposal may change this assumption. Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 > -Original Message- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 12:56 PM > To: Caitlin Bestler > Cc: Kanevsky, Arkady; [EMAIL PROTECTED]; > openib-general@openib.org; [EMAIL PROTECTED] > 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. > > - Sean > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
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. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Title: Message 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. The equivalent guarantee is provided on IP networks by the fact that raw sockets are not accessible by non-privileged applications. From: Kanevsky, Arkady [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 9:39 AMTo: Caitlin Bestler; [EMAIL PROTECTED]; openib-general@openib.org; [EMAIL PROTECTED]Subject: RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model Caitlin, how does it change the proposed protocol? Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 -Original Message-From: Caitlin Bestler [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 12:36 PMTo: [EMAIL PROTECTED]; openib-general@openib.org; [EMAIL PROTECTED]Subject: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model On an IP network, a non-privileged user is generally not capable of forging a source IP address and is typically prevented from using certain source ports. I would propose that the CM [MAY|SHOULD|MUST] enforce that a non-privileged user can only use a Source IP Address and Port that they would have been able to use following the normal stack path (or what it would have been in the case that there is no conventional IP stack associated with this path). So if IPoIB is installed, you would not be able to use any address that you would have been blocked from using over IPoIB. Or at least you would not be guaranteed that you could. I think that MUST is the correct level of enforcement, but it needs to be clear that the CM and OS *MAY* do this checking and that a userspace IB application cannot use the IB stack to perform IP spoofing. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kanevsky, ArkadySent: Tuesday, October 25, 2005 9:00 AMTo: openib-general@openib.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [dat-discussions] round 2 - proposal for socket based connection model Dear OpenIB, SWG and DAT members, enclosed is teh second version of the proposal. There are really 2 proposals that are related. The first one is encoding IP 5-tuple into REQ private data with small additional info for versioning and IB capabilities. The second is just a couple of ideas, not a real proposal, on maping of IP ports to IB Service IDs. Thanks everybody for tons of feedback and deep discussions. I appologize if I had missed something. Happy reading, Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 YAHOO! GROUPS LINKS Visit your group "dat-discussions" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model
Title: Message Caitlin, how does it change the proposed protocol? Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 -Original Message-From: Caitlin Bestler [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 12:36 PMTo: [EMAIL PROTECTED]; openib-general@openib.org; [EMAIL PROTECTED]Subject: [openib-general] RE: [dat-discussions] round 2 - proposal for socket based connection model On an IP network, a non-privileged user is generally not capable of forging a source IP address and is typically prevented from using certain source ports. I would propose that the CM [MAY|SHOULD|MUST] enforce that a non-privileged user can only use a Source IP Address and Port that they would have been able to use following the normal stack path (or what it would have been in the case that there is no conventional IP stack associated with this path). So if IPoIB is installed, you would not be able to use any address that you would have been blocked from using over IPoIB. Or at least you would not be guaranteed that you could. I think that MUST is the correct level of enforcement, but it needs to be clear that the CM and OS *MAY* do this checking and that a userspace IB application cannot use the IB stack to perform IP spoofing. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kanevsky, ArkadySent: Tuesday, October 25, 2005 9:00 AMTo: openib-general@openib.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [dat-discussions] round 2 - proposal for socket based connection model Dear OpenIB, SWG and DAT members, enclosed is teh second version of the proposal. There are really 2 proposals that are related. The first one is encoding IP 5-tuple into REQ private data with small additional info for versioning and IB capabilities. The second is just a couple of ideas, not a real proposal, on maping of IP ports to IB Service IDs. Thanks everybody for tons of feedback and deep discussions. I appologize if I had missed something. Happy reading, Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 YAHOO! GROUPS LINKS Visit your group "dat-discussions" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
