Hi Lee, Here are the things ORNL plans to build as part of this effort. Year 1 -- Initial prototype design for moving sw analytics close to storage resources Year 2 -- Proper prototype implementation of migrating sw analytics onto storage resources Year 3 -- Initial prototype design for extending memory-space onto storage system resources Year 4 -- Proper prototype implementation for extending memory-space onto storage system resources Year 5 -- Initial programming language extensions capable of mapping variables, etc onto storage resources If you want it in a text document, I can do that also. Cheers, Brad On 8/2/12 2:11 PM, "Richard Brooks" <[email protected]> wrote:
Modifications on my bullets based on Lee's and Phil's coments.
On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewerŠ
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb